Define durable session identity for ACP authorization

**What problem would this solve?**

ACP authorization currently combines a public session ID, persisted session type, and connection-local ownership. Session IDs may be reused after deletion, so a check against one persisted row can be followed by a load, prompt, fork, or mutation against a different row with the same ID. Connection-local ownership can also outlive the row it originally described.

This makes it difficult to define a race-free boundary between ACP-visible sessions, sessions created by the current connection, and internal sessions.

**What would a good outcome look like?**

Every ACP operation is authorized against the same durable session identity that it reads or mutates. Deleting and recreating a session must not transfer prior connection ownership or allow an operation authorized for the old row to act on the replacement.

The design should specify:

- whether public session IDs are globally non-reusable or paired with an immutable generation/row identity
- how a connection proves that it created the current persisted row
- how authorization and storage mutation are made atomic across concurrent delete/recreate operations
- which session types ACP may load, prompt, fork, rename, archive, truncate, update, or delete
- how existing persisted sessions and clients remain compatible

**Possible approaches**

- Make session IDs non-reusable and treat the ID as the durable identity.
- Add an immutable row UUID/generation and retain it with connection ownership, then require it in guarded storage operations.
- Provide transaction-scoped storage APIs that authorize and mutate the same row, combined with an immutable ownership token for connection-created internal sessions.

The accepted approach should cover both cached/active sessions and storage-only sessions without relying on a check-then-act sequence.

**Additional context**

A remediation attempt that added a shared ACP access check found that handler-level checks alone cannot close the delete/recreate race without choosing a durable identity and transaction contract. Implementation should wait for that contract rather than growing separate per-handler rules.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).