docs(architecture): clarify Backend trait scope and kv/sqlite framing

The backends spec read as if the Backend trait were a general storage
abstraction and 'two backends, exactly' banned other storage in a
deployment — so a downstream wanting sqlite manifests appeared forced
into implementing a third backend, the exact weld ADR-004 forbids.

- backends-and-dispatch.md: state plainly that the trait is a CAS-tier
  contract (immutable digest-keyed entries, GC-shaped list/delete) and
  never a host for manifest/index storage; consumer storage is
  beside-the-pool. 'Two, exactly' counts trait impls shipped, not
  storage per deployment. kv: tier name vs pinned sqlite engine made
  explicit.
- ADR-004: add the explicit corollary under the consumer-seams point.

docs/architecture/decisions/004-two-backends-no-third.md

@@ -57,6 +57,17 @@ boundary.)
      large-file ranges;
    - pinned batch puts — manifest-atomic multi-file writes are
      protected in flight (ADR-005).
+
+   Explicit corollary (added after a downstream misread): "consumers
+   build it on their own storage" means a consumer's manifest storage —
+   sqlite or whatever else — lives *beside the pool*, never behind the
+   `Backend` trait. The trait is a CAS-tier contract (immutable
+   digest-keyed entries, complete list, GC-participating delete); it
+   cannot express manifest storage, so a consumer implementing a
+   Backend to host a manifest was never a live option this boundary
+   forecloses — the boundary forecloses the crate *absorbing* such
+   layers, and the "no third backend" count is trait impls this crate
+   ships, not storage that may exist in a deployment.
 4. **Namespacing at the store level is logical only** (ADR-005):
    reference tables above, flat bytes below. If a consumer wants
    physical isolation per tenant/repo, that is two pool deployments (a