Shrink the post-revocation window: purge session state on observed revocation, pass a short max_ttl

From the privacy-policy legal review of 2026-08-03: "Complete immediate deletion of session credentials when revocation is observed. The current one-hour residual-access explanation is admirably transparent, but it remains a meaningful security limitation."

Current behaviour: revocation at id.ai takes effect in two steps (policy section 7): anything new stops within ~5 minutes, but an already-issued per-application delegation is reused from the session cache (Session.app_delegations, src/identities.rs) without an Internet Identity round-trip until it expires — up to 1 hour, II's default TTL, because mcp_prepare_delegation is called with max_ttl = null.

Two changes, both already identified in #114's review discussion:

1. Pass a short max_ttl (~5 minutes) to mcp_prepare_delegation so a cached delegation cannot meaningfully outlive revocation. Delegations are cached per (session, origin, account) and re-derived near expiry, so the cost is more derivation round-trips, not user-visible friction.
2. Purge on observed revocation: when a call through a delegated identity returns Unauthorized from Internet Identity or the network, drop the session's cached delegations (and treat the session as ended if the grant itself was revoked) instead of retrying or letting siblings be reused.

When it ships: the privacy policy's section 7 two-step revocation description and the retention table should be updated to the stronger guarantee (both files, plus the submission guides that repeat the ≤1 h window).

Start in src/identities.rs, following Session.app_delegations and the mcp_prepare_delegation call to understand caching and revocation-error handling. Done means delegations use a short max_ttl, observed Unauthorized responses purge the session cache and end revoked grants, and policy section 7, the retention table, and submission guides state the stronger guarantee.