Move subsystem state/locks off Daemon into owning types

Daemon no longer owns a coarse mu shared across unrelated concerns.
Each subsystem now carries its own state and lock:

- tapPool: entries, next, and mu move onto a new tapPool struct.
- sessionRegistry: sessionControllers + its mutex move off Daemon.
- opRegistry[T asyncOp]: generic registry collapses the two ad-hoc
  vm-create and image-build operation maps (and their mutexes) into one
  shared type; the Begin/Status/Cancel/Prune methods simplify.
- vmLockSet: the sync.Map of per-VM mutexes moves into its own type;
  lockVMID forwards.
- Daemon.mu splits into imageOpsMu (image-registry mutations) and
  createVMMu (CreateVM serialisation) so image ops and VM creates no
  longer block each other.

Lock ordering collapses to vmLocks[id] -> {createVMMu, imageOpsMu} ->
subsystem-local leaves. doc.go and ARCHITECTURE.md updated.

No behavior change; tests green.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

internal/daemon/ARCHITECTURE.md

@@ -7,16 +7,22 @@ against which the phased split described in
 
 ## Composition
 
-`Daemon` is a single struct aggregating state for every subsystem:
+`Daemon` is the composition root. Subsystem state and locks have moved onto
+owning types:
 
 - Layout, config, store, runner, logger, pid — infrastructure handles.
-- `mu sync.Mutex` — coarse lock, currently guards guest session controller
-  map mutations and image registry mutations.
-- `vmLocks sync.Map` — per-VM `*sync.Mutex`, one per VM ID.
-- `createOps`, `createOpsMu` — in-flight `vm create` operations.
-- `imageBuildOps`, `imageBuildOpsMu` — in-flight `image build` operations.
-- `tapPool`, `tapPoolNext`, `tapPoolMu` — TAP interface pool.
-- `sessionControllers` — active guest session controllers (guarded by `mu`).
+- `vmLocks vmLockSet` — per-VM `*sync.Mutex`, one per VM ID.
+- `createVMMu sync.Mutex` — serialises `CreateVM` (guards name uniqueness
+  + guest IP allocation window).
+- `imageOpsMu sync.Mutex` — serialises image-registry mutations
+  (`BuildImage`, `RegisterImage`, `PromoteImage`, `DeleteImage`).
+- `createOps opRegistry[*vmCreateOperationState]` — in-flight VM create
+  operations, owns its own lock.
+- `imageBuildOps opRegistry[*imageBuildOperationState]` — in-flight image
+  build operations, owns its own lock.
+- `tapPool tapPool` — TAP interface pool; owns its own lock.
+- `sessions sessionRegistry` — active guest session controllers; owns its
+  own lock.
 - `listener`, `webListener`, `webServer`, `webURL`, `vmDNS` — networking.
 - `vmCaps` — registered VM capability hooks.
 - `imageBuild`, `requestHandler`, `guestWaitForSSH`, `guestDial`,
@@ -28,23 +34,22 @@ Acquire in this order, release in reverse. Never acquire in the opposite
 direction.
 
 ```
-vmLocks[id]  →  mu  →  {createOpsMu, imageBuildOpsMu, tapPoolMu}
+vmLocks[id]  →  {createVMMu, imageOpsMu}  →  subsystem-local locks
 ```
 
+Subsystem-local locks (tapPool.mu, sessionRegistry.mu, opRegistry.mu,
+guestSessionController.attachMu/writeMu) are leaves. They do not contend
+with each other.
+
 Notes:
 
 - `vmLocks[id]` is the outer lock for any operation scoped to a single VM.
   Acquired via `withVMLockByID` / `withVMLockByRef`.
-- `mu` is currently load-bearing for both session controller lookups and
-  image registry changes. Holding it while calling into guest SSH is
-  discouraged; prefer copying needed state out under the lock and releasing
-  before blocking I/O.
-- The three subsystem locks (`createOpsMu`, `imageBuildOpsMu`, `tapPoolMu`)
-  are leaves. Nothing else is acquired while one is held.
-
-The upcoming Phase 2 refactor will retire `mu` entirely by giving each
-concern it currently guards its own owning type and lock. At that point
-the ordering collapses to `vmLocks[id]  →  subsystem-local lock`.
+- `createVMMu` and `imageOpsMu` are narrow: each guards one family of
+  mutations and is released before any blocking guest I/O.
+- Holding a subsystem-local lock while calling into guest SSH is
+  discouraged; copy needed state out under the lock and release before
+  blocking I/O.
 
 ## External API