fix(#838): write out lost_load_zone's ZoneAssetState arms so a new in-flight variant reds the binary crate

[djhenry]

Closes #838.

lost_load_zone is the decision function behind watch_for_lost_load, the only detector for a
zone-asset loader that died without reporting. It matched on ZoneAssetState with _ => None.

That wildcard is correct for every state that exists today — Idle, Ready and Failed should
all be left alone — which is what made it dangerous: it reads as deliberate, and it would go on
silently answering None for a fifth, in-flight variant added later. Such a state would then
never be declared lost, and an agent polling a frozen in-flight zone cannot tell "still loading, be
patient" from "nothing is coming, ever". That is the agent-honesty failure Failed exists to
prevent.

This PR writes the four arms out. One file, src/app.rs, +41/-2, comment-heavy; no behaviour
change — every existing state answers exactly what it answered before.

Relationship to #826/#837

#826 fixed the same class of wildcard on ZoneAssetState::collision() in crates/eqoxide-nav/.
Its rustdoc scopes this site out by name, and this PR is the named follow-up rather than a
contradiction of it:

What it does NOT prove [...]: (a) it covers exactly ONE function body and says nothing about
the other wildcards on this enum (status here, terrain_meshes in eqoxide-http,
lost_load_zone in the binary crate — see #838)

⚠️ Correction (round 5). This body previously said #826's own E0004 probe did not name
lost_load_zone "because the wildcard absorbed the new variant instead of erroring". That was
reasoned, not run, and it is false — the probe below is what falsifies it. A probe scoped to
eqoxide-nav reds that crate's own lib and stops there, so the crate holding src/app.rs is
never compiled and this match is never type-checked at all. A wildcard here and four explicit arms
here are indistinguishable to that invocation. The wildcard's danger is real; that particular probe
simply was not the thing that failed to see it. The rustdoc carried the same false sentence and is
corrected in 2f617b6.

Evidence: the E0004 probe

Method: add a fifth in-flight variant to ZoneAssetState, then cargo check the binary crate
(check -p eqoxide --locked) and read rustc's E0004 list. Run remotely; stdout and stderr captured
separately.

Round 1 — the probe does not reach the binary crate on its own. Adding the variant alone red
eqoxide-nav with 6 E0004s, all in crates/eqoxide-nav/src/zone_assets.rs (lines 105, 118,
154, 165, 356, 471 — tag, zone, collision, detail, usability, and the hand-written Debug
impl), and eqoxide was never compiled. Recording only this would have proved nothing about
src/app.rs. Each of those six matches was given a ProbeVerifying { .. } => todo!() arm so the
binary crate is actually type-checked.

Round 2 — positive control. With eqoxide-nav compiling and the arms in lost_load_zone
written out, cargo check -p eqoxide --locked reports exactly one E0004 in package
eqoxide (re-measured at 2f617b6; the line number below moved because the round-5 doc edit sits
above the function, and the previously published 118 was WIP-era numbering):

    Checking eqoxide v0.1.0
error[E0004]: non-exhaustive patterns: `&ZoneAssetState::ProbeVerifying { .. }` not covered
   --> src/app.rs:136:11
    |
136 |     match st {
    |           ^^ pattern `&ZoneAssetState::ProbeVerifying { .. }` not covered
error: could not compile `eqoxide` (lib) due to 1 previous error

src/app.rs:136 is lost_load_zone's match st {. Reach control: Checking eqoxide v appears
exactly once in that run. Adding --all-targets to the same -p eqoxide check changes neither
number (still 1 E0004, still src/app.rs:136:11).

Scope of "exactly one", stated properly. It is one per package eqoxide, not one in the
workspace. cargo check -p eqoxide-nav --all-targets --locked under the same probe reports one
further E0004, at crates/eqoxide-nav/src/zone_assets.rs:705:19 — inside #826's own test, which
deliberately matches the enum with no wildcard. That is a different package and is not part of the
count above. Within package eqoxide, the other wildcards on this enum — including terrain_meshes
in eqoxide-http — stayed silent under the same probe. They are real and out of this PR's scope.

Round 3 — negative control. Re-run at round 5 rather than inherited. Same probe variant still
in place, same filled arms in eqoxide-nav, only lost_load_zone reverted to its pre-#838
_ => None form:

• exit status: 0
• grep -c 'error\[E0004\]' on stderr: 0
• grep -cE '^error' on stderr: 0; grep -cE '^warning': 0
• last line: Finished \dev` profile [unoptimized + debuginfo] target(s) in 3.40s`
• reach control: Checking eqoxide v0.1.0 present exactly once in that run, so the crate really was
  re-checked and not served from a stale artifact.

So the E0004 is attributable to the match form, not to the probe variant merely existing.

Revert, with the stale-artifact trap closed. Both files were copied aside with cp -p and
restored from those copies, then touched — cp -p preserves mtime, so without the touch
cargo silently reuses the stale artifact and the "clean" run is a false control (md5sum does not
help: the source is right and the artifact is stale). The post-restore run shows fresh
Checking eqoxide-nav v0.1.0 and Checking eqoxide v0.1.0 lines, 0 errors, 0 warnings.

git diff crates/eqoxide-nav/src/zone_assets.rs after the revert: empty (wc -l = 0), and
git diff --stat origin/main..HEAD -- crates/eqoxide-nav/src/zone_assets.rs on the pushed branch is
likewise empty. The probe scaffolding is not in the shipped diff.

What the probe does not establish. Like #837's, this evidence is not a test and CI cannot re-run
it. It is a one-time measurement recorded here and in the rustdoc.

Why there is no lexical source-scanning guard here

#826 added audit_collision_arms, a comment-stripping, arm-wise scan of collision's body, as a
CI-runnable pin. This PR deliberately does not add a second one, and the residual risk is stated
rather than hidden:

• The property this PR buys is carried by rustc alone: a new ZoneAssetState variant reds
  src/app.rs with E0004 and forces an arm to be written at this site. Measured above, both
  directions. A second guard adds nothing to that.
• audit_collision_arms and its strip_comments state machine live inside
  #[cfg(test)] mod tests in crates/eqoxide-nav/src/zone_assets.rs (line 480), so they are not
  reachable from the binary crate. Adding a guard here would mean a second copy of that
  scanner, in a different crate, with its own evasion surface — fix(#826): make collision() and usability() fail to compile together on a new state variant #837 needed four review rounds and
  five measured evasions (comment-borne _, a }} in a trailing comment, an
  #[allow(unreachable_patterns)] _, an or-pattern | _, and a same-line second arm) to get one
  copy right. A second copy is a cost, not a bonus.
• What is therefore NOT covered, plainly: nothing stops a future author deleting these four arms
  and writing _ => None again. That reds no build and fails no test. It is exactly the residual
  risk zone_assets: collision()'s _ => None wildcard can make usable_collision's documented-unreachable arm reachable (#803 follow-up) #826 chose to pin for collision and this PR chooses not to pin for lost_load_zone. The
  rustdoc says so in the body ("it does not stop someone re-introducing a wildcard later") and ends
  with an explicit Do not collapse these arms back into _``.
• E0004 also does not make the new arm correct, only forced — the same limitation zone_assets: collision()'s _ => None wildcard can make usable_collision's documented-unreachable arm reachable (#803 follow-up) #826's rustdoc
  states as its point (b).

The three include_str!("app.rs") pins

src/app.rs is read as corpus by tests in other modules, so an edit here is not bounded by this
file. The include_str! pins were located (git grep -n 'include_str!'), read, and checked by
running them, not by reasoning:

Pin	What it asserts	Result
src/movement.rs:3520 the_zone_change_reload_block_still_forgets_the_recovery_ring	finds the if zone_needs_reload(...) block by text and asserts it contains self.controller.forget_recovery_history();	ok
src/movement.rs:3572 the_frames_that_do_not_step_still_clear_the_hold	anchors on the if self.camera_initialized { if let Some(c) = self.collision... head, walks to its } else {, asserts self.controller.clear_hold();	ok
src/zone_in.rs:1153 the_app_rs_scan_reads_a_balanced_file	brace balance of app.rs under a comment/string-aware stripper, plus APP_RS.len() > 50_000	ok
src/zone_in.rs the_app_rs_call_into_this_module_is_an_unconditional_statement	self.zone_in. occurs exactly once as code, un-nested, with five named args	ok
src/zone_in.rs the_zone_change_blocks_ring_clear_is_not_nested_behind_a_condition	self.controller.forget_recovery_history(); exactly once as code, innermost enclosing block head == the reload-block head	ok

The comment channel is the one that has defeated pins of this shape before, and this PR is mostly
comment. Counted in the added lines of the whole branch diff: self.zone_in. 0, forget_recovery_history 0,
clear_hold 0, zone_needs_reload 0, camera_initialized 0; no raw strings (r# 0); braces added
3 { / 3 }, all in real match patterns. So the added text introduces none of the tokens these
pins count, and all five run green.

⚠️ Correction (round 5): that grep is not a completeness argument. git grep -n 'include_str!'
enumerates the pins that read this file via include_str! and nothing else. At least two further
guards reach src/app.rs by walking the tree, and neither would appear in that grep. Both were
located and read at this head, with line numbers verified rather than quoted:

Site	How it reaches src/app.rs	Relationship to this diff
crates/eqoxide-nav/src/walker.rs:3652, inside exactly_one_production_fine_worker_is_built_in_the_tree_787 (fn at walker.rs:3542)	"src/app.rs" is a named reach-control anchor: the guard asserts the file is present in its corpus, then scans that corpus for Walker::new( / LocalPlanner::spawn( constructions	the round-5 diff adds neither token
crates/eqoxide-nav/src/steering.rs:1891 workspace_rs_files() (rustdoc from :1885), used as the resolution corpus by every_test_citation_in_the_four_citation_files_resolves_and_is_listed_in_a_guard (fn at steering.rs:1726)	walks crates/, tests/ and src/, so src/app.rs is in it; only its fn NAME declarations feed the resolution set	the round-5 diff adds no fn. Note src/app.rs is not in citation_corpus() (steering.rs:1874, four files), so this file's own doc comments are not scanned for citations — a test name cited in the text above would not be checked

Rather than argue from those readings, the whole eqoxide-nav suite was run before and after the
round-5 edit; see below. The honest form of the claim is: complete for include_str!-based pins,
not complete for everything that reads this file — the suite run is what covers the rest.

Doc correction made on top of the WIP commit

The WIP commit (1cfe4c9) asserted in rustdoc that the tests below lost_load_zone "stay green
under a probe variant". That was reasoned, not run, and it contradicts the paragraph it sits in:
with the arms written out, a fifth variant reds this file, so those tests do not run at all until an
arm is written. ece3def replaces it with the measured probe result above, and narrows "forces
whoever adds it to classify it as in-flight or terminal" to what E0004 really does — it forces a
decision at this site; it does not make the resulting arm correct. The same correction is applied to
the "what this test cannot do" note on a_pending_load_with_no_live_loader_is_declared_lost.

1cfe4c9's own commit message lists this work as outstanding; it is an already-pushed WIP message
and cannot be amended without a force-push (blocked here). This body supersedes it.

Suite

cargo test --workspace --locked --no-fail-fast at ece3def, stdout and stderr captured separately.

• compile sentinel: Finished `test` profile [unoptimized + debuginfo] target(s) in 24.46s
  (this is the COMPILE sentinel, not run-completion); 1 Compiling line
• 55 ^running [0-9]+ tests?$ headers vs 55 ^test result: lines — equality is the
  lost-binary check
• non-canonical stdout lines: 0
• targets with nothing to run: 14 (^running 0 tests$ = 14; ^test result: ok\. 0 passed; 0 failed; 0 ignored = 14).
  Looser patterns measured on the same log give unanchored running 0 tests = 14,
  [^0-9]0 passed; = 18, bare 0 passed = 21; the last two are artifacts of matching a zero in the
  failed/ignored/filtered fields, not extra empty targets.
• 1843 passed + 0 failed + 47 ignored + 0 filtered = 1890 = 1890 header total (all four terms)
• stderr ^error|panicked|Killed: 0; ^warning: 0

Base ef01926 measured in its own worktree runs 55/55 and 1843 + 0 + 47 + 0 = 1890. The figures are
identical, which is the expected result and is itself a check: #838 adds no test, so any delta
would have needed reconciling by name.

Not established

• No live run. This is a compile-time property plus existing unit tests; there is nothing to observe
  in a running client that was not already observable.
• The probe is not reproducible in CI (see above).
• terrain_meshes in eqoxide-http and status in eqoxide-nav are still wildcards on this same
  enum. The positive-control run confirms they stay silent under a fifth variant. They are out of
  scope here, as zone_assets: collision()'s _ => None wildcard can make usable_collision's documented-unreachable arm reachable (#803 follow-up) #826's rustdoc already records.

Round 5

Head 2f617b6. Comment-only on top of ece3def.

• Diff shape, proved not asserted. git diff -U0 ece3def..2f617b6 | grep '^[+-]' | grep -v '^[+-][+-]'
  is 27 lines; filtering out every line matching ^[+-][[:space:]]*(///|//) or ^[+-][[:space:]]*$
  leaves 0. The whole-branch non-comment diff against origin/main is still exactly the seven
  lines of the actual fix (the use ... as S; import and the four arms replacing _ => None).
• eqoxide-nav suite, before and after, same command
  (cargo test -p eqoxide-nav --locked --no-fail-fast): identical both runs —
  2 ^running [0-9]+ tests?$ headers vs 2 ^test result: lines,
  246 passed + 0 failed + 16 ignored + 0 filtered = 262 = the header total, one
  Finished `test` profile compile sentinel, ^error|panicked|Killed on stderr 0.
  This is the suite that matters for a comment-only change to src/app.rs, because two of its
  guards read that file as corpus (table above).
• Tree green at head: cargo check -p eqoxide --locked exits 0 with 0 errors and 0 warnings,
  Checking eqoxide-nav v and Checking eqoxide v each present once.
• Probe residue: git status --short clean after every probe; the mutated zone_assets.rs was
  restored from a cp -p copy and touched each time, and diff against the pristine copy is empty.

Still open after round 5

• The probe remains a one-time measurement, not something CI re-runs. Unchanged from round 4.
• Nothing stops a future author collapsing these arms back to _ => None. Deliberate; stated in the
  rustdoc and in the section above.

[djhenry]

BLOCKING FINDINGS — one blocking (a false mechanism sentence in a tracked file, plus its twin in this body), three non-blocking. The code is right: I attacked the change itself hard and could not break it. Every finding below is prose.

Reviewed independently at head ece3def, merge-base with origin/main = ef01926, in my own detached worktree. All builds remote, --locked.

---

MUST-FIX 1 — src/app.rs:117-119 states a mechanism that is false, and I measured it two ways

The rustdoc ends:

Same class of fix as #826/#837 on ZoneAssetState::collision(); that one is in
crates/eqoxide-nav/ and its E0004 probe did not name this site, because the wildcard absorbed
the new variant instead of erroring.

The body repeats it at "Relationship to #826/#837":

That sentence also states the mechanism this PR then measured: #826's own E0004 probe did not
name lost_load_zone, because the wildcard absorbed the new variant instead of erroring.

The "because" is wrong. The wildcard never got the chance to absorb anything.

Measurement A — #837's own record. #837's PR body states its probe was

cargo check -p eqoxide-nav --all-targets demanded arms at five sites and did not mention
collision()

-p eqoxide-nav does not build the binary crate at all, so src/app.rs was outside the
compilation-unit set. #837 did not miss this site via a wildcard — it never compiled the file. #837
says so itself two sections later: "I confirmed both unnamed sites at source", and filed #838 from
that reading, not from an E0004.

Measurement B — my own reach probe. Probe variant ProbeVerifying { zone: String } added to
ZoneAssetState, no arms filled, then check -p eqoxide --locked — i.e. requesting the binary
crate explicitly, the most generous case:

• Checking eqoxide v0.1.0 lines: 0 — the binary crate is never checked
• error[E0004] count: 6, all in crates/eqoxide-nav/src/zone_assets.rs (105:15, 118:15,
  154:15, 165:15, 356:24, 471:15)
• terminal: error: could not compile eqoxide-nav (lib) due to 6 previous errors

So even asking for -p eqoxide does not reach src/app.rs until those six arms are filled. That is
exactly what this PR's own round 1 found and wrote down ("eqoxide was never compiled") — the
body then contradicts its own round 1 four paragraphs earlier.

Why this is blocking rather than cosmetic. This is a reach claim, and it is the second one this
enum has produced. A future author reading line 118 will believe a #826-shaped probe reaches
src/app.rs, and will draw the wrong conclusion from a green -p eqoxide-nav run. It also makes the
positive property one notch weaker than the rustdoc states at lines 105-110 ("adding a variant to
ZoneAssetState makes this file fail to compile with E0004"): true for a build that compiles
the binary crate, not true for the -p eqoxide-nav check that the person adding a variant to
eqoxide-nav would naturally run first. That is a real and unstated narrowing of the thing the PR
exists to buy.

Suggested replacement for 117-119:

/// Same class of fix as #826/#837 on `ZoneAssetState::collision()`; that one is in
/// `crates/eqoxide-nav/`, and its E0004 probe did not name this site for a reason that has
/// nothing to do with the wildcard: #837 ran `cargo check -p eqoxide-nav --all-targets`, which
/// never builds the binary crate, so `src/app.rs` was outside the compilation-unit set entirely.
/// #837 identified this site by reading and filed #838. Measured on the #838 PR: with the probe
/// variant added and `-p eqoxide` requested *explicitly*, `eqoxide-nav` reds first with 6 E0004s
/// and `eqoxide` is never checked at all (zero `Checking eqoxide` lines). The wildcard's
/// absorption becomes observable only once those six arms are filled — which is what the
/// negative control does.

and a clause on line 106 so the property is stated no wider than measured — e.g. makes **this file fail to compile** with E0004 *in any build that compiles the binary crate* (a -p eqoxide-nav check reds inside that crate first and stops short of this file).

The body's "That sentence also states the mechanism…" should go too: the quoted #826 scope note is
about the lexical guard's coverage; it says nothing about any probe's reach. The quote itself is
verbatim-accurate — I checked it against crates/eqoxide-nav/src/zone_assets.rs:1133-1135 — it
is only the gloss on it that is wrong.

---

NON-BLOCKING 2 — the evidence block's line number is from the WIP commit, not from head

Body: --> src/app.rs:118:11, and then "src/app.rs:118 is lost_load_zone's match st {".

At ece3def that match is at line 123. My positive control (probe variant + all six
eqoxide-nav arms filled + these four arms written out), check -p eqoxide --locked:

error[E0004]: non-exhaustive patterns: `&ZoneAssetState::ProbeVerifying { .. }` not covered
   --> src/app.rs:123:11
error: could not compile `eqoxide` (lib) due to 1 previous error

Checking eqoxide v0.1.0 present, count 1. So 118 is the WIP commit 1cfe4c9's numbering, run
before the round-3 doc rewrite that added five rustdoc lines, and it is presented as the shipped
state. The finding is only provenance — the result reproduces exactly, one E0004, right site — but
line 118 at head is now the sentence carrying MUST-FIX 1 above, which is an unlucky coincidence
worth not shipping. Please re-quote at 123 or drop the number.

---

NON-BLOCKING 3 — the include_str! grep cannot find the guards that actually read app.rs

Body: "src/app.rs is read as corpus by tests in other modules, so an edit here is not bounded by
this file. All three sites were located (git grep -n 'include_str!')".

git grep include_str! is structurally incapable of finding a whole-repo walker. There are at
least two more consumers of src/app.rs-as-text, found by searching for the corpus rather than the
macro:

• crates/eqoxide-nav/src/walker.rs:3646-3654 — the nav: local_planner_dead's "session-scoped" name rests on "exactly one fine worker per process", which nothing pins #787 guard's REACH CONTROL 2 anchor list
  contains the literal "src/app.rs" and asserts it is in the corpus. It then greps every file for
  Walker::new( / LocalPlanner::spawn(.
• crates/eqoxide-nav/src/steering.rs:1885-1907 — workspace_rs_files() walks crates/, tests/
  and src/ as the citation-resolution corpus.

Both are green here and both are green for a reason: this PR adds none of walker.rs's two needles,
and steering.rs's corpus is a resolution target where added text can only add resolvable citations,
never remove one. So the outcome is fine, and the full-workspace run covers it. What is wrong is
the claim of completeness attached to a method that could not have produced it. Suggest either
scoping the sentence to "all three include_str! sites" without the "read as corpus by tests in
other modules" frame, or adding a row for the two walkers with the reason each is direction-safe.

---

NON-BLOCKING 4 — "exactly one E0004 in the whole crate" is over lib+bin only (checked; it survives)

check -p eqoxide without --all-targets excludes src/app.rs's #[cfg(test)] mod tests and the
crate's ten integration-test targets, so "the whole crate" is looser than what was run. I checked
whether that matters:

• ZoneAssetState appears nowhere in the root crate's tests/ directory (grep, 0 hits).
• The only other ZoneAssetState site in src/ is src/app.rs:797, a matches!(…, Pending { .. } if …),
  which is not exhaustive and can never red.

So the claim holds; only the word "crate" is imprecise. I could not measure it end-to-end because
check --workspace --all-targets with the probe stops at crates/eqoxide-nav/src/zone_assets.rs:705:19
— #826's own deliberately-exhaustive test match, which round 1's -p eqoxide-nav (no --all-targets)
did not surface. Worth knowing if anyone re-runs this probe: round 1's six sites are six for lib
only; with --all-targets it is seven.

---

What I attacked and could NOT break (negative results)

• Is lost_load_zone dead code? No. Traced end to end: src/app.rs:2299 self.maybe_finish_load()
  inside window_event on WindowEvent::RedrawRequested → src/app.rs:891
let Some(load) = result else { return self.watch_for_lost_load() }; → src/app.rs:955-967
watch_for_lost_load → src/app.rs:958 lost_load_zone(!self.load_threads.is_empty(), &st).
  any_loader_alive is false exactly when load_threads.retain(|h| !h.is_finished()) has emptied
  the vec, which is the intended trigger. The function is live on the render path. (One unverified
  aside, pre-existing and out of scope: in a frame mode that schedules no redraw, maybe_finish_load
  is not called at all, so the watchdog's cadence depends on redraws — not something this PR
  touches.)
• Negative control re-run from scratch, with the stale-artifact trap closed. Probe variant + six
  filled arms still in place, only lost_load_zone reverted to S::Pending {..} => Some(...), _ => None,
  file touched after the cp -p: error[E0004] = 0, ^error = 0, and a genuine fresh
  Checking eqoxide v0.1.0 line, Finished dev profile … in 1.54s. The E0004 really is attributable
  to the match form. The body's control is sound.
• Round 1 reproduced exactly. Six E0004s at zone_assets.rs 105:15, 118:15, 154:15, 165:15,
  356:24, 471:15 — identical to the reported set, including the column numbers.
• Reach control on the "other wildcards stayed silent" claim. I checked the positive-control log
  for whether eqoxide-http was actually recompiled under the probe rather than served from cache —
  Checking eqoxide-http v0.1.0 is present. So "terrain_meshes in eqoxide-http stayed silent"
  has a real reach control behind it, and the residual disclosure in "Not established" is honest.
  I independently located that wildcard at crates/eqoxide-http/src/observe.rs:50-53
  (ZoneAssetState::Ready { terrain_meshes, .. } => Some(*terrain_meshes), _ => None) and agree it
  is out of scope here and correctly disclosed, not hidden.
• zone_assets: collision()'s _ => None wildcard can make usable_collision's documented-unreachable arm reachable (#803 follow-up) #826 scope-note quote: verbatim against crates/eqoxide-nav/src/zone_assets.rs:1133-1135.
• Behaviour: the four arms are extensionally identical to the old Pending-plus-wildcard form
  for all four existing variants. No behaviour change, as claimed.
• Suite: base ef01926 at 1843 passed / 0 failed / 47 ignored is independently corroborated by
  PR fix(#780): make reporting the joint-cap downgrade a precondition of choosing a render arm #843's separately-authored base measurement of the same commit. I did not re-run the workspace
  suite for this PR (this PR adds no test, so the expected delta is zero and the two figures agree).
• The decision not to add a lexical guard: I think it is right and honestly stated. The residual
  ("nothing stops a future author deleting these four arms and writing _ => None again. That reds
  no build and fails no test") is the correct residual, stated plainly rather than buried, and the
  argument against a second copy of strip_comments in another crate is sound given fix(#826): make collision() and usability() fail to compile together on a new state variant #837's five
  measured evasions. No finding.

---

Fix MUST-FIX 1 (one rustdoc paragraph plus one clause, and the matching body sentence) and I have
nothing else blocking. Worktree restored; git status --porcelain empty at ece3def.

[djhenry]

Round 5 pushed as 2f617b6. Comment-only; the seven real code lines of the fix are untouched.

The blocking finding: confirmed false, and I measured the thing that falsifies it

The rustdoc said #826's E0004 probe did not name this site "because the wildcard absorbed the new
variant instead of erroring". Adding a fifth in-flight variant to ZoneAssetState and running
cargo check -p eqoxide-nav --locked:

• error[E0004] count: 6, all in crates/eqoxide-nav/src/zone_assets.rs (lines 104, 117, 153,
  164, 355, 470 at that mutated head), terminating with
  error: could not compile `eqoxide-nav` (lib) due to 6 previous errors
• grep -cE '^ *Checking eqoxide v': 0

So src/app.rs is never compiled by that invocation and this match is never type-checked. A
wildcard here and four explicit arms here are indistinguishable to it. The wildcard's danger is
real — that probe just wasn't the thing that failed to see it. The rustdoc now says so in those
terms, and names it explicitly as a claim an earlier draft made without running.

Which invocation actually reds this file

Filling the six nav arms with => todo!() (arms inserted immediately after each reported match
line, bottom-up so numbering does not drift):

    Checking eqoxide v0.1.0
error[E0004]: non-exhaustive patterns: `&ZoneAssetState::ProbeVerifying { .. }` not covered
   --> src/app.rs:136:11

Checking eqoxide v = 1 (reach control), error[E0004] = 1. --all-targets on the same
-p eqoxide check: also 1, also 136:11. The rustdoc now states both the invocation that bites and
that -p eqoxide-nav does not.

136, not 118 or 123. 118 was WIP-era. It measured 123:11 at ece3def — and then my own doc edit,
which sits above the function, pushed it to 136:11. I re-ran the probe against the final file
content rather than trusting the earlier number, and grep -n 'match st {' on the pushed head agrees.
The body's code block is updated to 136.

Negative control — re-run here, not inherited

Probe variant in place, six nav arms filled, lost_load_zone reverted to _ => None:
exit 0, error[E0004] 0, ^error 0, ^warning 0, last line
Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.40s, Checking eqoxide v0.1.0
present exactly once.

Non-blocking items

"exactly one E0004 in the whole crate" — narrowed to package eqoxide. Measured:
cargo check -p eqoxide-nav --all-targets --locked under the same probe reports one further E0004 at
crates/eqoxide-nav/src/zone_assets.rs:705:19, inside #826's own no-wildcard test. Named in the body
as a different package rather than left to contradict the count.

The include_str! completeness claim — you were right that it was not established, and I am not
claiming it now. git grep -n 'include_str!' enumerates include_str!-based pins and nothing else.
I read both tree-walking sites and verified the line numbers myself rather than quoting them:

• crates/eqoxide-nav/src/walker.rs:3652 — "src/app.rs" in the named-anchor reach control of
  exactly_one_production_fine_worker_is_built_in_the_tree_787 (fn at walker.rs:3542). It asserts
  the file is in the corpus, then scans for Walker::new( / LocalPlanner::spawn(.
• crates/eqoxide-nav/src/steering.rs:1891 — workspace_rs_files() (rustdoc from :1885) walks
  crates/, tests/, src/, so this file is in the resolution corpus of
  every_test_citation_in_the_four_citation_files_resolves_and_is_listed_in_a_guard (fn at
  steering.rs:1726). Only fn NAME declarations from it feed the resolution set. Worth recording:
  src/app.rs is not in citation_corpus() (steering.rs:1874, four files), so this file's own
  doc comments are not scanned for citations — a test name cited in this rustdoc would not be checked.

The claim in the body is now scoped to what the grep supports, and the suite run below is what
covers the rest.

Deliverables

Comment-only, proved mechanically. git diff -U0 ece3def..2f617b6 | grep '^[+-]' | grep -v '^[+-][+-]'
= 27 lines; after filtering ^[+-][[:space:]]*(///|//) and ^[+-][[:space:]]*$, 0 remain.
The whole-branch non-comment diff against origin/main is still just the use ... as S; line and the
four arms replacing _ => None.

eqoxide-nav suite, totals unchanged. cargo test -p eqoxide-nav --locked --no-fail-fast, run
once with the edit and once with src/app.rs restored to ece3def (git status --short clean for
the baseline run). Byte-identical figures:

	headers	result lines	passed	failed	ignored	filtered	sum	header total
ece3def app.rs	2	2	246	0	16	0	262	262
2f617b6 app.rs	2	2	246	0	16	0	262	262

One Finished `test` profile compile sentinel each; ^error|panicked|Killed on stderr 0 each.
This is the suite that matters for a comment-only edit to src/app.rs, since two of its guards read
that file. I did not re-run the full workspace for a comment-only change — the round-4 workspace
figures in the body stand, and I am flagging that I did not re-measure them rather than implying I did.

Probe hygiene. Every mutation was cp -p-copied aside, restored from the copy and touched;
diff against the pristine copy is empty and git status --short is clean after each. The
post-restore run shows fresh Checking eqoxide-nav v and Checking eqoxide v lines, 0 errors,
0 warnings — so no result above came from a stale artifact.

One process note against myself

The first attempt at the arm-filling probe used a shared anchor string that occurs four times in
zone_assets.rs; the edit script asserted uniqueness, tripped, and wrote nothing — and the
cargo check that ran afterwards silently re-measured the previous probe's state. Caught by the
assertion, but the failure mode is a script that "runs" and produces a number belonging to a
different mutation. Every probe reported here was re-derived after that, with the reach control
(Checking eqoxide v count) read on each run.

Still open

• The probe is a one-time measurement; CI does not re-run it. Unchanged from round 4.
• Nothing prevents a future author collapsing these four arms back to _ => None. Deliberate, and
  stated in both the rustdoc and the body.