docs: clarify phase boundaries — Phase 1 vs downstream concerns

The architecture specs were implying that StorageIdentityProvider, irpc
service implementations, and application services (agent, Docker, etc.)
already exist. This commit makes the phasing explicit:

- services.md: deployment topology now clearly labels 'Current (Phase 1)'
  vs 'Future (Phase 2+)', notes that application services are downstream
- identity.md: StorageIdentityProvider labeled 'Future — Phase 2+',
  clarifying alknet-storage doesn't exist yet
- storage.md: adds phase note that the crate hasn't been built yet,
  StorageIdentityProvider is a future impl
- ADR-028: ConfigAuthService is Phase 1 path, StorageAuthService is
  Phase 2+ contract
- call-protocol.md: Agent Service Pattern section explicitly framed as
  a downstream application concern, not a core requirement

docs/architecture/decisions/028-auth-irpc-service.md

@@ -81,14 +81,15 @@ feature is disabled, auth goes through `IdentityProvider` directly.
 
 ### AuthServiceImpl
 
-Two implementations exist:
+Two implementations exist (the second is a future phase):
 
 - **ConfigAuthService** — backed by `ConfigIdentityProvider` (ArcSwap path).
   Wraps the trait in an irpc service for deployments that use the service layer
-  but don't have SQLite.
+  but don't have SQLite. This is the Phase 1 path: it ships with alknet-core.
 - **StorageAuthService** — backed by SQLite `peer_credentials` and `api_keys`
-  tables (in alknet-storage). Queries on demand. Can maintain an LRU cache for
-  hot fingerprints. This is the production implementation.
+  tables (in alknet-storage, not yet built). Queries on demand. Can maintain an
+  LRU cache for hot fingerprints. This is a Phase 2+ implementation — the
+  contract is defined here so alknet-storage can implement it later.
 
 Both produce the same `AuthResult` — an `Identity` or a denial. Callers don't
 know or care which backend is running.