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).

The issue concerns ACP (Access Control Policy) authorization for sessions. Research the session management and ACP modules in the codebase, focusing on how session IDs are generated, stored, and validated. Look for existing session types, connection ownership logic, and storage APIs. The goal is to design a durable identity system that prevents race conditions between delete and recreate operations.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.