P16: AI Connections activity view + honest disconnect

[ehsan6sha]

P16 — AI Connections: activity view + honest disconnect (FxFiles)

Follow-up to P13 (AI Connections) / P14 (workspace adoption) on the feat/fula-mcp track. Two user-facing gaps in the AI Connections feature:

1. Honest disconnect copy

The "Remove connection?" dialog implied the local delete was the whole story. In reality, disconnecting only deletes FxFiles' local pairing record — it does not instantly revoke the AI's access:

• The AI holds a short-lived, scoped session JWT.
• It cannot renew that token — the issuer's refresh endpoint rejects MCP tokens (401).
• So the AI keeps working until the token reaches its exp (about an hour by default; at most 24h if the instance set a longer TTL), then is permanently locked out.
• Files it already stored stay in the user's library.

The dialog must state this truthfully and must not imply instant revocation.

2. AI activity view ("What AIs have stored")

There was no way to see what AI assistants have written into the shared encrypted AI workspace. Add a screen, reachable from the AI Connections screen, that lists the shared workspace contents (listWorkspaceObjects('fula-ai-workspace', prefix: 'ai/') — key, size, modified date).

This view is collective: every AI connection derives the same workspace secret (no connection identity), so a file is "AI-created" but cannot be attributed to a specific connection. The UI states this plainly. Gated so non-AI users see nothing; loading / empty / error states.

Acceptance

• Disconnect dialog copy is truthful (expiry-bound, not instant) with a documented immediate-revoke follow-up.
• AI activity screen lists the shared workspace, framed as collective with no per-connection attribution, gated behind hasAiConnection().
• FFI-free unit tests (FakeFulaApi + mocked SecureStorage): activity gated-empty vs populated; disconnect calls deleteConnection.
• flutter analyze lib/features/ai_connections clean; new tests green.

Immediate-revoke follow-up (documented, out of scope here)

True ~30s revocation needs a server-side connection-revoke: (1) bind the minted token's jti to the connection's mcp_pub_b64 at mint; (2) a DELETE /api/mcp/tokens/connection/{mcp_pub_b64} endpoint that blocklists that jti; (3) a gateway FULA_MCP_REVOCATION_ENABLED flag gating the check.