Lift the 50-char per-tag length limit on diary entries

[legreffier]

Problem

The agent in task `10be8447` repeatedly hit `Validation Failed: body/tags/3 must NOT have more than 50 characters` when trying to write diary entries with realistic provenance tags. The 50-char cap is too tight once we factor in:

• Auto-injected task tags (`task:id:` = 41 chars, `task:correlation:` = 50 chars exactly — hits the cap with no headroom).
• Agent-chosen scope/branch tags like `branch:feat/issue-747-publish-moltnet-json-schema` (49 chars, also right at the cap).
• Future cross-task linking tags (`task:parent:`, `task:supersedes:`, etc.).

The validation rejects the entire entry create, so a few-character overage on a single tag silently loses the entire diary write.

Surface area

Schema-side, ~7 occurrences of `maxLength: 50` to update:

• `libs/models/src/schemas.ts:71`, `:79`, `:86` — `tags` field in CreateDiaryEntry, UpdateDiaryEntry, and search filter schemas.
• `apps/rest-api/src/routes/diary-distill.ts:126,129,204,207` — inline TypeBox tag-array shapes on four endpoints.

DB side: `libs/database/src/schema.ts` — tags are stored as a postgres array; verify there's no column-level constraint to bump.

CLI side: `apps/moltnet-cli` doesn't pre-validate, so no change needed there (the API is the authoritative gate).

Proposed fix

Bump the per-tag `maxLength` from 50 → 128. Rationale:

• 128 fits a `task:correlation:` (50 chars) plus comfortable headroom for any future namespacing scheme.
• Still tight enough to keep the postgres array fields manageable — diary search performance won't change.
• The `maxItems: 20` array cap stays; per-entry total tag budget is ~2.5 KB worst case, fine for our index.

Drop-in changes:

```diff

• Type.Array(Type.String({ maxLength: 50 }), { maxItems: 20 }),

• Type.Array(Type.String({ maxLength: 128 }), { maxItems: 20 }),
  ```

Apply uniformly across all 7 sites. Add a regression test in `libs/models/tests/schemas.test.ts` asserting a 128-char tag passes and a 129-char tag fails.

Out of scope

• Increasing `maxItems` (20-tag-per-entry cap). The issue we hit was per-tag length, not count.
• Schema-versioning / migration. Validation is purely additive (loosening a constraint).
• CLI pre-validation. Adding it later would be a UX nicety but isn't blocking.

Cross-references

• Surfaced during task `10be8447-edf2-406e-93ef-b7f29391c919` (the first real end-to-end agent-daemon PR, feat(cli): publish JSON Schema for moltnet.json #1120).
• Diary entry `ad8666b5-a748-4f2e-a306-1a6b6d02d2e5` for that task includes the failed-tag observation context.