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/identity.md

@@ -96,13 +96,16 @@ impl IdentityProvider for ConfigIdentityProvider {
 }
 ```
 
-### StorageIdentityProvider (Production)
+### StorageIdentityProvider (Future — Phase 2+)
 
-Implemented in `alknet-storage` (not in alknet-core). Backed by SQLite
-`peer_credentials` and `api_keys` tables plus the ACL graph. Resolves
-fingerprint → account → organization membership → effective scopes. Uses the
-`IdentityProvider` trait defined in alknet-core, providing the concrete impl via
-the trait.
+Implemented in `alknet-storage` (a crate that doesn't exist yet). Backed by
+SQLite `peer_credentials` and `api_keys` tables plus the ACL graph. Resolves
+fingerprint → account → organization membership → effective scopes.
+
+This implementation is defined here so the contract is clear, but alknet-storage
+hasn't been built yet. Phase 1 uses `ConfigIdentityProvider` exclusively. When
+alknet-storage is built, it implements alknet-core's `IdentityProvider` trait,
+and the CLI/NAPI assembly layer wires the concrete implementation.
 
 ### AuthProtocol irpc Service
 
@@ -132,7 +135,8 @@ The relationship:
   which internally delegates to `AuthProtocol::VerifyPubkey` via an irpc client.
   Used in production deployments with SQLite-backed auth.
 
-Both paths produce the same `Identity` result.
+Both paths produce the same `Identity` result. Note: the irpc path requires the
+service layer to be built (Phase 2+). Phase 1 uses the trait path exclusively.
 
 ### Auth Flows