reconcile promised-but-absent backends + client with reality

[hartsock]

Context

README.md's Architecture lists five substrate backends and a client crate that
do not exist in the workspace (they are commented out of the Cargo.toml
members): nessie-backend-s3, nessie-backend-nfs (bare NFS),
nessie-backend-ontap (passthrough), nessie-backend-p4d, nessie-backend-gitlfs,
and nessie-client (plus the advertised pip install nessie-store-client). Only
the zfs and mem backends are real.

The durable-docs pass fixes the immediate inaccuracy — the README now carries a
machine-checked crate inventory (scripts/check-doc-drift.sh) that separates
implemented from planned and cannot silently drift. This issue tracks the
follow-through: decide, per crate, build-and-milestone vs. formally defer, so
"planned" is a real plan and not a permanent aspiration.

Scope

• For each planned backend, decide: assign a target milestone + file a build
  issue, or mark it explicitly deferred (with the reason).
• Prioritize against the roadmap — the ontap-passthrough and s3 backends
  are the most externally useful; p4d / gitlfs also underpin the
  experimental demand-paged NFS gateways.
• nessie-client + unified Python (Face B): schedule as a concrete milestone
  or mark deferred. The README advertises pip install nessie-store-client, so
  there is an external contract to either honor or retract.
• Keep the README crate inventory and the check-doc-drift.sh guard in sync as
  each crate lands (move it from planned to implemented).

Acceptance

• Every "planned" crate in the README inventory has either a build issue + a
  milestone, or an explicit deferral note. No phantom crate is presented without a
  decision behind it.