meta: let a single shard be taken out of service

[bjmeetsfo]

The problem

ShardLocation records where a shard lives and nothing about whether it should be served. So there is no way to take one shard out of service. The only lever is freezing its whole table, which stops every other shard in that table too.

That is the wrong granularity for the cases it comes up in: one shard is corrupt, or hot, or under investigation, and the rest of the table is fine.

What this adds

A state on ShardLocation, and three operations: POST /shards/freeze, /shards/unfreeze, /shards/drop.

A frozen shard keeps its owner entry — that is what lets unfreezing put it back where it was — but stops being served. Dropping removes the route outright rather than leaving a tombstone: a shard has no identity beyond where it is served from.

The field defaults to Normal, so shard entries written before this load as serving.

The part that matters: nothing may fight the operator

Freezing a shard is only useful if the rest of the metaserver respects it. Four paths read placement, and all of them now go through one serving_shard_owners view:

• Topology — a frozen shard is handed to clients with no primary and no replicas.
• Rebalance (both planners) — will not move it. Moving a shard an operator deliberately froze is the planner undoing a decision.
• Divergence check — will not flag it. Its owner not serving it is exactly what freezing means, so flagging it would have the checker "repair" the operator's intent.
• Orphan guard — a frozen shard does not count as something a conviction would strand.

A hole the tests caught

My first attempt filtered the frozen shard's recorded owner out of build_shards. That was not enough: the general candidate scan still picked a primary for it through the replicas.first() fallback, so the shard stayed routable and the topology test failed with primary: Some("node-a").

A shard that is not serving now gets no placement computed at all — the loop emits an empty entry and moves on. That is the honest semantic: the shard still occupies its key range, but nothing is serving it.

Tests

9 new tests: freezing one shard leaving the rest of the table serving (and the table itself untouched), unfreezing restoring it, the owner entry surviving a freeze, rebalance leaving it alone, the divergence check ignoring it, drop removing the route and reporting shard_not_found on a second attempt, unknown/unchanged rejections, the topology-version bump, and state surviving both a snapshot round trip and mutation-log replay.

Verification:

• cargo test -p temporalstore-rust --lib meta -- --test-threads=1 — 261 passed, 0 failed.
• cargo test -p temporalstore-rust --lib client -- --test-threads=1 — 33 passed, 0 failed.
• cargo test -p temporalstore-rust --bin metaserver -- --test-threads=1 — 18 passed, 0 failed.
• cargo build -p temporalstore-rust --bin metaserver — clean.

No gate: the field defaults to serving, so nothing changes until an operator freezes something.