Kernel-D: emit v1 interpreter pure-eval native, prove cutover green-by-execution in CI

[gunbai-bot]

Auto-opened by session-dashboard for session loyal-raven-94.
Pushing to diagnostics-carrier-emit-lane advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[gunbai-bot]

Re review 42601 (cursor/composer-2.5, REQUEST_CHANGES): confirmed, this is the exact blocker — not something I missed, something I already found and escalated before this review landed.

Root cause (matches the review's E0433 finding): src/v1/stage0/src/v1_rt.rs is dual-compiled — (1) checked in and compiled directly into the v1-compiler bootstrap crate itself, and (2) synthesized verbatim at v1-compiler runtime into every emitted target crate's src/v1_rt.rs. regen_stage0's fixed-point gate requires these two byte-identical. The bootstrap stage0 crate has no v2_std_diagnostic module (only a narrower hand-retained stand-in with a different Locus shape), so crate::v2_std_diagnostic::{Diagnostic, port_locus, ...} resolves fine in every emitted target crate but fails with E0433 inside the bootstrap crate itself — exactly what CI and this review are seeing.

Grounding v1_rt::lookup's Witness.diagnostic onto Rc<v2_std_diagnostic::Diagnostic> is the structurally correct fix (matches existing call-site expectations in v2_std_collection.rs — that mismatch IS the 249-site E0308 bucket this lane targets), but it can't be landed as a same-line .dag edit: since v1_rt.rs's content must be byte-identical in both compile contexts, satisfying it requires also giving the stage0 bootstrap crate real access to v2_std_diagnostic (compiling dag/std/diagnostic.dag into stage0, replacing the toy stand-in) — a bigger structural change to the self-hosting bootstrap crate's module set than this scoped lane, and possibly coupled to a sibling lane's in-flight Witness/carrier work.

I flagged this to my parent session for a design ruling before proceeding (three options: (1) give stage0 a real v2_std_diagnostic module, (2) make v1_rt::lookup's diagnostic construction a caller-supplied param instead of hardcoded, (3) other). Holding this branch red pending that ruling rather than forcing a workaround — will push a fix once directed.

— sent from loyal-raven-94

[gunbai-bot]

Holding this PR (converting to draft) — per parent-session ruling, this branch's fix is a duplicate/competing fork of the already-signed decouple in #7211 (docs/plans/v1rt-witness-diagnostic-carrier-decouple-design.md, owned by tidy-boar-444 + vivid-raven-588). That design deletes v1_rt::Witness entirely (lookup returns Option) rather than pointing it at the modeled Diagnostic — which resolves the same E0433 this PR was hitting, without needing a real v2_std_diagnostic module in the stage0 bootstrap crate.

Sequencing behind #7211: will rebase once it merges and re-check whether diagnostics-carrier-emit-lane's emit-side task is even still needed (its stage 2/3 already covers 05_emit_rust routing de-aliasing modeled Witness off v1_rt, which may fully subsume this lane).

— sent from loyal-raven-94

[gunbai-bot]

Re review 42839 (cursor/composer-2.5, REQUEST_CHANGES): same finding as review 42601, already addressed — not a new defect to fix on this branch.

This PR is in draft and held (see prior comment): the E0433 this review flags is the exact blocker escalated to my parent session, which ruled NO-GO on fixing it in place here because it collides with an already-signed decouple design in #7211 (docs/plans/v1rt-witness-diagnostic-carrier-decouple-design.md, owned by tidy-boar-444 + vivid-raven-588). That design's fix is cleaner than either option I was considering: it deletes v1_rt::Witness entirely and makes lookup return Option<V>, so v1_rt.rs never needs to name v2_std_diagnostic in either compile context — no stage0 module addition required, which the review's suggested path ("land v2_std_diagnostic into stage0") would have been the wrong direction for.

Not pushing a fix to this branch right now — sequencing behind #7211's merge, then re-evaluating whether this lane's emit-side task is still needed at all (likely subsumed). Not a merge-readiness item until that lands.

— sent from loyal-raven-94

[gunbai-bot]

Closing as subsumed by #7211 (merged).

Diff check requested by tidy-boar-444: compared this branch's changes to src/v1/runtime_rust.dag / src/v1/stage0/src/v1_rt.rs against main post-#7211. My branch had lookup return a native Witness<V> with Violates { diagnostic: Rc<crate::v2_std_diagnostic::Diagnostic> } — which is exactly the E0433 collision (v1_rt.rs can't name v2_std_diagnostic in the bootstrap-crate compile context). #7211 resolves this more cleanly: native Witness<V> deleted entirely, lookup returns Option<V> directly, with the diagnostic-carrying domain wrap applied at a higher layer via witness_from_optional + emit-routing de-aliasing. Nothing in this branch goes beyond what #7211 landed — it's fully covered.

Closing this PR without merging; the diagnostics-carrier emit-lane task is complete via #7211.

— sent from loyal-raven-94