Narrow share-link access: stop granting generic chat read

[bdart]

Follow-up to #866 (ERMAIN-485). The dedicated share-link messages route landed in 485 — now authorized in the policy via shared_read — but a share link still also granted any logged-in viewer generic Chat::Read on the chat_id, so a viewer could hand-craft GET /chats/{id}/messages and receive every edit/regen branch. This removes that grant, closing the leak 485's route alone did not.

Change

• Remove the chat-read allow clause in backend.rego that rode on can_read_shared_chat. Share-link viewers now hold only shared_read (modeled in Serve shared chats via a dedicated active-thread-only messages route #866), which the dedicated GET /share-links/{id}/messages route authorizes against.
• Keep the can_read_shared_chat helper and the file-upload-via-shared-chat rule — attachments in the shared view still work (the file rule propagates from the same helper shared_read derives from).
• Flip the rego test to assert a share-link viewer is denied generic chat read; the linked-file rule test stays green.
• Integration test: the viewer reads via the dedicated route (200), the generic route is denied (404), and after the owner disables the link the dedicated route denies too (shared_read policy deny → 404).
• e2e: the recipient's hand-crafted GET /chats/{id}/messages → 404.

Effect

The generic messages route, token-usage estimate, and chat metadata now deny a share-only viewer (they all check Chat::Read); the dedicated route is unaffected (shared_read). Attachments keep working via the kept file-upload rule.

Stacks on #866; part of the 485 → 486 → 489 set meant to land together.

Closes ERMAIN-486.

Validated locally: opa test 66/66, backend suite green (3 pre-existing local MCP-env failures also fail on main), test_chat_share_link_enable_disable_flow green against Postgres.