fix: an unreadable own label refuses the launch instead of falling through

`find_release` gave the provider's own `<provider>/…` token the last word, but only
when that token parsed. When it did not, the loop fell through and kept scanning, so
any other release in the banner could stand in for the one the provider had just
named. `omp/18.1.0-rc1 18.0.9` admitted on the stray `18.0.9` and launched a provider
that reported itself as an unverified 18.1 pre-release — the exact outcome the
function's own doc comment promises to prevent.

The label now decides outright: if what the provider named cannot be parsed, the
answer is `None` and the caller fails closed. Both shipped banners are unaffected,
which was checked rather than assumed — omp prints `omp/18.0.11`, which parses, and
opencode prints a bare `1.18.25`, which never enters the labelled branch at all.

Latent today because the real binaries print one token each, but DQ-OMP-5 is open on
precisely the update banner that would add a second one, and the exact-version gate
that used to mask this is gone: keying on the minor means a stray token only has to
land in an admitted series, not match a version exactly.

Found by independent verification of #370 as mutation S6: deleting the fall-through
left the suite byte-identical, so nothing asserted it. Two tests now do, one on the
parser and one driving the production gate through a fake provider. Both go red under
S6 in either shape — restoring the `continue`, or deleting the labelled branch
outright.

agent-identity: dev3.dotfiles.omp.admission-18-0-9.worker
agent-persona: worker
agent-supervisor: dev3.dotfiles-lead
agent-tool: Claude Code
agent-tool-version: 2.1.251
agent-runtime: Claude Code 2.1.251
tooling-profile: dotfiles@6048b77

Author: schickling-assistant

docs/vrs/06-omp-driver/spec.md

@@ -53,6 +53,12 @@ Shape of `pi_session.rs`:
   from decaying into "starts with 18" — minors are compared numerically (`18.10` is not `18.1`),
   exactly three components are required, and a pre-release or build-metadata suffix
   (`18.0.9-rc1`) does not parse at all, so it is never admitted as its base release.
+  Which token the release is read FROM matters as much as how it parses: an `omp/<release>`
+  token is omp naming itself and decides outright, and if what it named cannot be parsed the
+  gate refuses rather than reading some other token in the banner. Otherwise `omp/18.1.0-rc1
+  18.0.9` would launch an unverified provider on the strength of a version omp never claimed —
+  which is the shape DQ-OMP-5's update banner could produce. With no own label, every parseable
+  release in the banner must agree.
 - Injects the channel extension from the verified hook set (`with_channel_extension` shape —
   resolved from this binary's immutable asset, never a catalog-pinned path).
 - Applies offline defaults (`PI_OFFLINE=1`, `PI_SKIP_VERSION_CHECK=1`) unless the operator's

src/harness_version.rs

@@ -68,22 +68,25 @@ pub fn parse_release(token: &str) -> Option<Release> {
 /// unverified 18.1. So the provider's own label wins, and an unlabelled banner is only trusted
 /// when it is unambiguous:
 ///
-/// 1. a `<provider>/<release>` token is authoritative — it is the provider naming itself;
-/// 2. otherwise every parseable release must agree, since a single release repeated across lines
-///    is still unambiguous;
-/// 3. anything else (no release, or two disagreeing ones) is `None`, and the caller fails closed.
+/// 1. a `<provider>/…` token DECIDES, because it is the provider naming itself. If what it named
+///    parses, that is the answer; if it does not, the answer is `None` — the search stops rather
+///    than falling through, or `omp/18.1.0-rc1 18.0.9` would admit on a release omp never
+///    claimed;
+/// 2. with no own label, every parseable release must agree, since a single release repeated
+///    across lines is still unambiguous;
+/// 3. anything else (no release, an unreadable own label, or two disagreeing ones) is `None`, and
+///    the caller fails closed.
 pub fn find_release<'a>(printed: &'a str, provider: &str) -> Option<(&'a str, Release)> {
     let labelled = format!("{provider}/");
     let mut unlabelled: Option<(&'a str, Release)> = None;
     let mut ambiguous = false;
 
     for token in printed.split_whitespace() {
         if let Some(rest) = token.strip_prefix(labelled.as_str()) {
-            // The provider naming itself outranks anything else in the banner.
-            if let Some(release) = parse_release(rest) {
-                return Some((rest, release));
-            }
-            continue;
+            // The provider naming itself outranks anything else in the banner — including the
+            // case where what it named cannot be read. Falling through to the rest of the banner
+            // would let a stray token stand in for a release the provider never claimed.
+            return parse_release(rest).map(|release| (rest, release));
         }
         let bare = token.strip_prefix('v').unwrap_or(token);
         let Some(release) = parse_release(bare) else {
@@ -193,6 +196,29 @@ mod tests {
         );
     }
 
+    /// The provider naming itself with something this parser cannot read is a REFUSAL, not a
+    /// reason to keep looking. Falling through to the rest of the banner is how the gate ends up
+    /// bound to a token the provider never claimed: `omp/18.1.0-rc1 18.0.9` would admit on the
+    /// stray `18.0.9` and launch a provider that just said it was `18.1.0-rc1`. DQ-OMP-5 leaves
+    /// open whether omp's update banner adds exactly such a second token.
+    #[test]
+    fn an_unreadable_own_label_fails_closed_instead_of_falling_through() {
+        // The banner from the finding: an own label that does not parse, plus a stray release
+        // whose minor IS admitted. Reading the stray one is the whole bug.
+        assert!(find_release("omp/18.1.0-rc1 18.0.9", "omp").is_none());
+        // Not specific to pre-releases: any unreadable own label ends the search.
+        assert!(find_release("omp/nightly 18.0.9", "omp").is_none());
+        assert!(find_release("omp/ 18.0.9", "omp").is_none());
+        // The same parser backs the opencode gate, so it fails closed the same way.
+        assert!(find_release("opencode/1.18.25-beta 1.18.19", "opencode").is_none());
+        // An own label that DOES parse still decides, so the refusal above is about
+        // unreadability and not about labels in general.
+        assert_eq!(
+            find_release("omp/18.0.11 18.0.9", "omp").unwrap().0,
+            "18.0.11"
+        );
+    }
+
     /// A label that belongs to a DIFFERENT provider must not be read as this provider's version.
     #[test]
     fn another_providers_label_does_not_satisfy_this_provider() {

src/omp_session.rs

@@ -388,6 +388,24 @@ mod tests {
         );
     }
 
+    /// The refusal must survive omp naming itself with something unreadable. Found by independent
+    /// verification of #370 (mutation S6): deleting the labelled fall-through left the suite
+    /// byte-identical, and driving this gate with `omp/18.1.0-rc1 18.0.9` ADMITTED the launch,
+    /// bound to the stray token rather than to the release omp reported for itself. Latent while
+    /// the shipped binary prints one token, but DQ-OMP-5 is open on precisely the update banner
+    /// that would add a second.
+    #[test]
+    fn an_unreadable_own_label_cannot_be_rescued_by_a_stray_admitted_version() {
+        let fake = FakeExecutable::new("#!/bin/sh\nprintf 'omp/18.1.0-rc1 18.0.9\\n'\n");
+        let error = verify_supported_version(fake.path().to_str().unwrap())
+            .expect_err("an unreadable own label must not admit on a stray 18.0.9")
+            .to_string();
+        assert!(
+            error.contains("no unambiguous omp release"),
+            "the refusal must say the banner named no release it could read: {error}"
+        );
+    }
+
     /// Minors are compared as numbers. `18.10` must not pass on the strength of admitted `18.0`,
     /// which is how a minor gate would decay into "accept anything that starts with 18".
     #[test]