Manage owner-installed client grants, revocation and secrets

[haed]

Purpose

Implementation iteration of #35. Give owners list, grant assignment/update, revoke and secret-rotation operations over registered service clients.

Acceptance

• List zero-grant and granted registrations without returning stored secrets. Make last-grant removal preserve the registration and permit later assignment and rotation.
• Authorize each grant write independently of installer lifecycle scope: owner consent bound to the exact service client and grant set, or independently covering context authority. Installer scope alone cannot grant all contexts the owner could manage.
• Keep grant assignment outside OAuth registration metadata. If immediate installation grants are selected in A pod owner cannot register a service client for their own pod #35, implement a separate pod-rendered consent transaction after the assigned service identity exists. Bind it to the browser session, exact client/grants and once-only submission; implement the agreed return, refusal and CLI/polling completion grammar. ConsentTransactionStore is a starting shape, not already this transaction.
• Revocation removes the registration, prevents future Client Credentials minting and preserves data contexts. Rotation returns a new secret once without deleting context data. Define and test how already-issued service tokens behave after revoke/rotation, without promising stronger revocation than the mechanism delivers.
• Cover read-only access to existing contexts and optional private sandbox creation from the server-assigned ID. Ownership is alias-aware and pod-scoped; no caller-selected identifier bypass.
• Test denied/widened/replayed grant writes, list isolation, zero grants, last-grant removal, regrant, rotate, revoke and concurrency as appropriate.

Starting evidence

The current DAO can list rows internally, but host-admin provisioning/replacement is the public lifecycle surface; owner management is not implemented. Context cascade currently deletes empty registrations. Inspect those contracts together with the protected-registration changes.

Update docs/auth/service-clients.md, docs/auth/oauth.md for consent, relevant KDoc and Context7. Record the compatibility choice for existing registrations.

Completion

Follow issue work and run documentation-sync in every PR. Record applicable checks, changed documentation or a specific no-change reason. Before implementation, inspect affected stored rows and public contracts and record migration, compatibility or intentional PoC breakage. Close only after the stated acceptance and required merged work are verified. No release milestone is assumed.