fix(organization): cap BrandContextSchema's id field length

[pedrofrxncx]

Every free-text field on BrandContextSchema (packages/shared/src/organization/schema.ts) is capped at MAX_BRAND_STRING_LENGTH (500 chars) except id — the one field left as a bare z.string().

id is client-supplied on BRAND_CONTEXT_UPDATE (apps/api/src/tools/organization/brand-context-update.ts) and flows straight into a Kysely WHERE id = ... lookup (apps/api/src/storage/brand-context.ts). The query is parametrized so there's no injection risk, but an org member with ordinary brand-write permission could send an arbitrarily large id string in the request body with no validation catching it before it reaches storage — the same missing-validation-on-untrusted-input class every sibling field on this schema already guards against.

Fix: add the existing MAX_BRAND_STRING_LENGTH cap to id, matching every other field on the schema.

Failure scenario before the fix: BRAND_CONTEXT_UPDATE with a multi-KB id string passes schema validation and reaches the DB lookup unchecked.

Reviewer check: bun test packages/shared/src/organization/schema.test.ts — includes a new regression test asserting a 501-char id is rejected.

Locally ran: bun run fmt, cd packages/shared && bunx tsc --noEmit, the targeted test above, and bunx oxlint on both changed files — all clean. Full CI validates the rest.

---

Summary by cubic

Caps BrandContextSchema's id field at MAX_BRAND_STRING_LENGTH (500 characters), matching the validation on every other free-text field. Previously, id was an unbounded string, so a client could submit an arbitrarily long id that reached storage without being caught. Now such inputs are rejected during schema validation.

^{Written for commit bf6beca. Summary will update on new commits.}