zone_assets: collision()'s `_ => None` wildcard can make usable_collision's documented-unreachable arm reachable (#803 follow-up)

[djhenry]

Split out of the round-2 review of #821 (fix for #803). Both are non-blocking — the reviewer
said it would merge over both, and #821 was merged as 223ac9b.

1. collision()'s wildcard is the seam that can make a documented-unreachable arm reachable

usable_collision() ends with

state.collision().ok_or(NotUsable::Idle)

and its comment says that arm is unreachable, because usability returns None only for Ready
and Ready's collision field is not an Option. That is true today and it is pinned today:
usable_collision_agrees_with_usability_for_every_state enumerates all five current state variants
against five zone spellings, and forcing the fallback reachable turns ten tests red.

But the two functions disagree about how they will react to a sixth variant:

pub fn collision(&self) -> Option<&Arc<Collision>> {
    match self { Self::Ready { collision, .. } => Some(collision), _ => None }
}

collision() has a _ => None wildcard. usability matches without one. So a new state that
carries a usable grid would make usability fail to compile — the desired outcome — while
collision() silently returns None and the "unreachable" arm starts firing, turning a usable grid
into a refusal.

The pin catches this only if someone remembers to add the new variant to the test's states vec.
The compiler should be the thing that catches it. Replacing the wildcard with explicit arms makes
the two functions fail together.

Worth doing because the whole point of #803 was to stop a refusal and an answer from being
confusable, and this is the one remaining place where adding a state quietly converts one into the
other.

2. Write down why the case-sensitivity asymmetry is safe

usability compares zone names with eq_ignore_ascii_case; zone_needs_reload compares them
exactly. The round-2 review ruled this safe and the reasoning is worth keeping in-tree, because it
is not obvious and it runs the opposite way to intuition:

zone_needs_reload is strictly more eager than usability, so a case difference can only
cause a spurious reload — Pending, then an honest 503. It cannot produce a stale-but-blessed
grid.

Without that sentence the asymmetry reads as an oversight, and the tempting "fix" is to make
zone_needs_reload case-insensitive too — which removes the eagerness that makes the current
arrangement safe. One comment at the comparison site.

[djhenry]

Correction to this issue's own text, so it does not propagate further (found in the PR #837 round-1 review, B2).

This issue says the pin "enumerates all five current state variants". ZoneAssetState has four variants — Idle, Pending, Ready, Failed. The five is a count of the test's states vec, where readyA and readyB are both Ready with different zone names.

The consequence is that the issue's "a sixth variant" is really a fifth. PR #837 inherited the off-by-one into three tracked comments, including one inside a paragraph headed "Measured, not reasoned"; all three are corrected in that PR. tag()'s own rustdoc lists exactly four tags, and rustc's E0004 arm list confirms the count independently.

Nothing else in the issue is affected — the mechanism, the wildcard, and both asks are unchanged and correct.

One substantive ruling against this issue's part 2, also from that review, recorded here rather than only in the PR: the issue says making zone_needs_reload case-insensitive "removes the eagerness that makes the current arrangement safe". Worked through independently by both the PR author and the reviewer, that edit drops the pair to parity rather than breaking it — safety then depends on the (true, but unenforced) assumption that two zone shortnames differing only in ASCII case denote the same zone. The eagerness is a margin, and the margin is what would be lost, not the safety. The comment written in #837 says that, rather than the stronger claim. The edit that does break the rule outright is any comparison in zone_needs_reload more lenient than usability's.

The reviewer added a further point neither the issue nor the original comment had: scene.zone and the player_zone handed to usability are both copies of a single gs.world.zone_name, so a case-only divergence between the two sides cannot arise from the data flow at all. That makes the margin cheap insurance against a scenario the code already excludes — which is how the comment now frames it.