feat(create/monitor): implement automatic UUID materialization, auto-pinning, and drift-C2 resolution (13/13 PASS)

.agents/MULTI_AGENT_RULES.md

@@ -57,6 +57,13 @@ Asynchronous communication and state management between agents are controlled vi
   - **Job Registry**: The metadata and lifecycle of each asynchronous job are recorded in individual JSON files (`.mam/jobs/<id>.json`). Concurrency conflicts (claiming races) across multiple sessions are prevented via file-based `fcntl` advisory locks (`registry_lock` via `registry.py`).
   - **Session Registry**: TMUX monitoring states and running agent metadata are consistently controlled using a SQLite WAL database (`.mam/agent-sessions.db`) to support reliable concurrent transactions on a single host. However, since SQLite WAL mode does not guarantee complete file locking in Network File System (NFS) environments, we recommend using a local file system.
 
+### 🔑 Session ID Lifecycle & Auto-Assignment Protocol
+- **Auto-Assignment at Creation**: Fresh `claude` sessions automatically generate a random UUID (`mam_gen_uuid`) passed via `claude --session-id <uuid>`. `claude_session_id_own` is recorded in `.mam/agent-sessions.yaml` with `session_id_source: assigned` and `session_id_verified: false`.
+- **First Message Materialization**: Transcripts `.jsonl` are only created on disk when the first prompt message is delivered.
+- **Reconciler Confirmation (C0)**: The monitor loop (`reconcile.sh`) verifies the transcript on disk and promotes `session_id_verified: true` and `last_visible_status: pinned`.
+- **Ambiguity Guard (C-ambiguous)**: Unassigned sessions matching multiple candidate transcripts are flagged as `C-ambiguous` without random pinning.
+- **Path Equivalence**: All path calculations (`mam_abs_workspace`, `mam_workspace_key`) canonicalize symlinks (`cd -P && pwd -P` / `os.path.realpath`) ensuring 100% key match.
+
 ### 🛡️ Security Protocol (HMAC-SHA256)
 - **Unauthenticated PoC Mode**: If the `auth_token` in the job registry is set to `null` (the default PoC mode), signature verification is skipped and all events are accepted (`verify_hmac` always returns `True`).
 - **Authenticated Production Mode**: In production environments or integrations requiring authentication, a unique cryptographic token (`auth_token`) is issued for each job. The publisher must include an `hmac_sig` signature in the payload keyed by this token, and the receiving end (`verify_hmac`) will immediately drop messages that lack a signature or have mismatching signatures to prevent downgrade attacks.