tasks: clarify phase boundaries in remaining task descriptions

The remaining task descriptions implied that downstream concerns
(StorageIdentityProvider, irpc service layer, agent services, multi-node
deployment) already exist. Updated to clearly distinguish:

- spec-update-server: Phase 1 ships ConfigIdentityProvider, not irpc auth
- spec-update-call-protocol: Phase 1 is local dispatch only; irpc and remote
  dispatch are contracted for later. Agent services are downstream concerns.
- spec-update-overview: Note which crates exist now vs which are Phase 2+ contracts
- review-spec-foundation: Add phase boundary check to acceptance criteria

tasks/architecture/spec-update-server.md

@@ -19,10 +19,12 @@ level: implementation
 
 Update `docs/architecture/server.md` to reflect the architectural changes from Phase 1: DynamicConfig, ForwardingPolicy in channel handling, IdentityProvider replacing direct ServerAuthConfig reads, and the interface abstraction concept.
 
+**Phase boundary note**: Phase 1 ships `ConfigIdentityProvider` (ArcSwap-backed) as the only `IdentityProvider` implementation. The irpc `AuthProtocol` and `StorageIdentityProvider` are contracted in the specs but not built yet. Server.md should describe what the server actually does in Phase 1 — reading auth from `ArcSwap<DynamicConfig>` via `ConfigIdentityProvider` — with a forward reference to identity.md for the full trait hierarchy. Don't describe irpc service wiring or SQLite-backed auth as if they exist.
+
 The current server.md is thorough but reflects the alpha architecture where auth is read directly from `ServerAuthConfig` and there's no forwarding policy concept.
 
 **Changes needed**:
-1. Update Authentication section: auth delegation goes through `IdentityProvider` trait (reference identity.md, ADR-028), not direct `ServerAuthConfig` reads
+1. Update Authentication section: auth goes through `IdentityProvider` trait (reference identity.md, ADR-029), with `ConfigIdentityProvider` as the Phase 1 impl reading from `ArcSwap<DynamicConfig>` (reference ADR-030). Note that `StorageIdentityProvider` is a future implementation.
 2. Add ForwardingPolicy check in Channel Handling section: before proxy spawn, evaluate ForwardingPolicy against Identity (reference configuration.md, ADR-031)
 3. Replace `Arc<ServerAuthConfig>` with `Arc<ArcSwap<DynamicConfig>>` in ServerHandler description (reference ADR-030)
 4. Add note about Interface abstraction: SSH is one interface (Layer 2), ServerHandler logic maps to SshInterface (reference interface.md, ADR-026) — but detail is in interface.md, not here
@@ -33,14 +35,15 @@ The current server.md is thorough but reflects the alpha architecture where auth
 
 ## Acceptance Criteria
 
-- [ ] Authentication section updated: references IdentityProvider trait, not just ServerAuthConfig
+- [ ] Authentication section updated: references `IdentityProvider` trait with `ConfigIdentityProvider` as Phase 1 impl, notes `StorageIdentityProvider` as future
 - [ ] Channel Handling section updated: ForwardingPolicy check before proxy spawn, reference ADR-031
 - [ ] ServerHandler struct updated: `Arc<ArcSwap<DynamicConfig>>`, not `Arc<ServerAuthConfig>`
 - [ ] Note added about Interface abstraction pointing to interface.md and ADR-026
 - [ ] CLI section mentions `--config` flag (TOML) and `[[listeners]]` for multi-transport
 - [ ] Single-transport constraint softened (noted as current, changing per ADR-030)
+- [ ] Phase boundary clear: what ships in Phase 1 vs what's contracted for later
 - [ ] `last_updated` in YAML frontmatter updated
-- [ ] ADR table updated with references to 026, 028, 030, 031
+- [ ] ADR table updated with references to 026, 028, 029, 030, 031
 - [ ] References section updated to include configuration.md, identity.md, interface.md
 
 ## References