feat(assistants): viewer/editor share permissions UI (#113)

[philmerrell]

PR 2 of 2 for #113 — consumes the backend contract shipped in #383.

Summary

• Share dialog: per-row "Can view / Can edit" selector on existing shares, a "permission for new people" toggle that applies to all newly added emails, and `onSave` delta-detection that separates adds, removes, and permission upgrades on already-shared emails — each routed to the right backend endpoint (`POST` / `DELETE` / new `PATCH /assistants/{id}/shares`).
• Assistant list: shared-with-me cards with `userPermission === 'editor'` now show an "Editor" badge and an Edit button alongside Chat (owners' actions unchanged).
• Assistant form: owner-only gating on the Share button; "Shared by {owner}" banner for editors; `userPermission` tracked from the loaded assistant (with a safe owner fallback for create mode).
• Contract shape: `AssistantSharesResponse.sharedWith` is now `ShareEntry[]` (`{email, permission}`) end-to-end. The pre-existing `sharedEmails: string[]` state in the dialog became `shares: ShareEntry[]`.

Why this lands now

PR 1 changed `AssistantSharesResponse.sharedWith` from `string[]` to `ShareEntry[]` — the SPA was reading the old shape until this PR. Merging promptly closes that gap.

Test plan

• `npm run test:ci` → 1101 passed. New spec coverage:
  • Service: `shareAssistant` default + explicit-permission, `updateSharePermission`, `getAssistantShares` returning `ShareEntry[]`.
  • Dialog: dedicated spec for the delta algorithm (pure add, pure remove, permission upgrade on existing email, no-change baseline, mixed adds + removes + upgrades). DI tokens used over `vi.mock` per project convention.
• `npm run build` → clean (only pre-existing budget + unused-RouterLink warnings).
• Manual smoke (script below — `SKIP_AUTH=false` locally so I can't exercise it autonomously):

Manual test script

Setup: two accounts. Alice owns an assistant; Bob has no shares yet.

1. Owner shares Bob as viewer
   • As Alice → open the assistant → Share → enter `bob@…` → permission toggle stays on "Can view & chat" → Save.
   • Expected: dialog closes, no error.
2. Bob sees viewer state
   • As Bob → assistants list → "Shared with Me" section shows the assistant card with the owner badge, no "Editor" badge, no Edit button (just Chat).
3. Owner upgrades Bob to editor
   • As Alice → Share dialog → Bob's row → flip permission select to "Can edit" → Save.
   • Network: a `PATCH /assistants/{id}/shares` should fire (not `DELETE` + `POST`).
4. Bob sees editor state
   • As Bob → reload list → his card now shows the amber "Editor" badge and an Edit button next to Chat.
5. Bob edits as editor
   • As Bob → click Edit → form opens with all fields editable, the amber "Shared by Alice" banner in the header, no Share button.
   • Change description, Save. Expected: 200; navigates back to list.
6. Bob cannot change visibility
   • As Bob → set visibility (via any indirect path that triggers `visibility` on the PUT, e.g. share dialog clear-all → it tries PRIVATE). Expected: backend 400 surfaces in the dialog as an error.
7. Mixed save
   • As Alice → Share dialog → add a new viewer email, remove an existing share, downgrade one editor → Save.
   • Expected: one `POST` (adds), one `DELETE` (removes), one `PATCH` per downgraded email. Watch network tab.

🤖 Generated with Claude Code