arch: recurring ToolExecutor wrapper-forwarding defect class needs a compiler-enforced fix, not more one-off patches

[bug-ops]

Description

The ToolExecutor wrapper-forwarding gap (a decorator's own impl ToolExecutor for Wrapper<T> block omits an override for a cross-cutting trait method, silently falling through to the trait's permissive default instead of forwarding to self.inner) has now recurred as at least three separate, independently-discovered groups within roughly two months:

1. checkpoint_undo/redo/list not forwarded by TrustGateExecutor/PolicyGateExecutor/AdversarialPolicyGateExecutor, breaking /undo in standard production wiring #5899/checkpoint_undo/redo/list not forwarded by ScopedToolExecutor/ShadowProbeExecutor — breaks /undo even after #5899, since these sit outside the gated chain #5905/ScopedToolExecutor does not forward requires_confirmation, defaulting to false for the outermost wrapper #5906 (checkpoint trio + requires_confirmation on TrustGateExecutor/PolicyGateExecutor/AdversarialPolicyGateExecutor/ScopedToolExecutor) — fixed by fix(tools): forward checkpoint and confirmation methods through executor wrappers #5930
2. CompositeExecutor does not forward requires_confirmation; AdversarialPolicyGateExecutor does not forward is_tool_speculatable #5900/CompositeExecutor does not override execute_tool_call_confirmed, silently re-running the full confirmation check on the composed tree #5938/PolicyGateExecutor/AdversarialPolicyGateExecutor do not forward requires_confirmation #5931 (requires_confirmation/is_tool_speculatable/execute_tool_call_confirmed on CompositeExecutor/AdversarialPolicyGateExecutor/PolicyGateExecutor) — fixed by fix(tools): forward requires_confirmation/is_tool_speculatable/execute_tool_call_confirmed through remaining ToolExecutor wrappers #6011
3. checkpoint_undo/redo/list never reach ShellExecutor — Arc<ShellExecutor>'s own ToolExecutor impl doesn't forward them #5985 (Arc<ShellExecutor> shadow-impl checkpoint forwarding) — fixed by fix(tools): forward checkpoint methods through Arc<ShellExecutor> #5998
4. CompressedExecutor/ToolFilter/Arc<ShellExecutor>-style shadow-impls have the same ToolExecutor forwarding gap as #5900/#5938/#5931 #6012 (open) — CompressedExecutor/ToolFilter/Arc<ShellExecutor>-style shadow-impls, same shape again, plus the CompressedExecutor checkpoint-trio gap noted in a follow-up comment on that issue

Every occurrence has the same root cause: ToolExecutor (crates/zeph-tools/src/executor.rs:676) gives every cross-cutting method (requires_confirmation, is_tool_speculatable, execute_tool_call_confirmed, checkpoint_undo/checkpoint_redo/checkpoint_list, is_tool_retryable, set_skill_env, set_effective_trust) a permissive default. Rust does not warn when a trait impl silently relies on a default instead of overriding it — there is no compiler signal distinguishing "this wrapper intentionally has no confirmation policy" from "this wrapper's author forgot to forward requires_confirmation to self.inner". Each fix so far has been a manual, per-PR audit of "which wrapper is missing which method this time", which does not scale and has already missed things twice within the same review cycle (#6011's own follow-up issue #6012 already needed a same-day amendment for a checkpoint-trio gap the issue author didn't catch on the first pass).

The trait doc itself already flags an adjacent instance of "manual duplication where the compiler won't catch a missed method" for the separate ToolExecutor/ErasedToolExecutor two-trait split (executor.rs:669-673, "D2 — deferred: consolidate ToolExecutor and ErasedToolExecutor... every new method must be added to both traits"), so this is a known, named pattern in the codebase's own TODOs, not a novel observation.

Proposed Fix (needs an architectural decision, not a code PR)

Two viable directions, either would close this permanently:

Option A — delegation macro. Most affected wrappers (ToolFilter, CompressedExecutor, ScopedToolExecutor, ShadowProbeExecutor, PolicyGateExecutor, AdversarialPolicyGateExecutor, TrustGateExecutor) hold exactly one inner: T field and plain-delegate the majority of methods, overriding only a handful for wrapper-specific behavior (e.g. execute, execute_confirmed). This is the textbook use case for a trait-delegation macro (e.g. the ambassador crate, which supports #[delegate(Trait, target = "inner")] with per-method #[delegate(automatic)]/skip overrides and has async-trait support) or a small hand-rolled macro_rules! that expands to a full pass-through impl block, with wrapper-specific methods written manually afterward and shadowing the macro-generated ones. Precedent in this codebase: #299 ("refactor: AnyProvider delegate macro", closed) solved the analogous problem for AnyProvider. CompositeExecutor (dual-inner, OR-forwarding semantics) doesn't fit the single-target delegate pattern and would keep its current hand-written impl — it's a smaller, already-well-tested surface.

Option B — remove defaults for the risk-bearing subset. Make requires_confirmation, checkpoint_undo, checkpoint_redo, checkpoint_list, is_tool_speculatable, and execute_tool_call_confirmed required (no default body) on ToolExecutor. Every current impl site (leaf and wrapper) must then explicitly implement them, which is a one-time compile-error-driven audit across the ~19 files with impl ToolExecutor for — after that, no future wrapper can silently inherit a wrong default, because the compiler forces an explicit choice at the call site. Leaf executors that genuinely have no checkpoint/confirmation semantics just write the same trivial body they'd get from the default today (CheckpointActionResult::unsupported(), false, etc.) — the point isn't to change behavior, it's to make "I looked at this method and chose the default" distinguishable from "I forgot this method exists" at compile time.

A is less invasive to leaf executors but requires picking and vetting a new dependency (or maintaining a hand-rolled macro); B needs zero new dependencies and is arguably more idiomatic for a trait this security-sensitive, but touches every existing impl site once.

Impact

Not itself a live vulnerability — every confirmed instance so far has been caught before reaching a currently-reachable production wiring (see #6012's dormancy note). The impact is velocity and review cost: this is the 4th grouped discovery of the same shape, each requiring a full manual re-audit of every impl ToolExecutor for site, and each audit has had a nonzero miss rate within the same session (#6012 itself needed same-day amendment). Left unaddressed, it will keep recurring every time a new cross-cutting method is added to the trait or a new wrapper is introduced.

Related

• checkpoint_undo/redo/list not forwarded by TrustGateExecutor/PolicyGateExecutor/AdversarialPolicyGateExecutor, breaking /undo in standard production wiring #5899/checkpoint_undo/redo/list not forwarded by ScopedToolExecutor/ShadowProbeExecutor — breaks /undo even after #5899, since these sit outside the gated chain #5905/ScopedToolExecutor does not forward requires_confirmation, defaulting to false for the outermost wrapper #5906 → fixed by fix(tools): forward checkpoint and confirmation methods through executor wrappers #5930
• CompositeExecutor does not forward requires_confirmation; AdversarialPolicyGateExecutor does not forward is_tool_speculatable #5900/CompositeExecutor does not override execute_tool_call_confirmed, silently re-running the full confirmation check on the composed tree #5938/PolicyGateExecutor/AdversarialPolicyGateExecutor do not forward requires_confirmation #5931 → fixed by fix(tools): forward requires_confirmation/is_tool_speculatable/execute_tool_call_confirmed through remaining ToolExecutor wrappers #6011
• checkpoint_undo/redo/list never reach ShellExecutor — Arc<ShellExecutor>'s own ToolExecutor impl doesn't forward them #5985 → fixed by fix(tools): forward checkpoint methods through Arc<ShellExecutor> #5998
• CompressedExecutor/ToolFilter/Arc<ShellExecutor>-style shadow-impls have the same ToolExecutor forwarding gap as #5900/#5938/#5931 #6012 (open) — latest instance, needs the fix from whichever option is chosen here
• refactor: AnyProvider delegate macro #299 (closed) — prior precedent for a delegate-macro solving the same category of problem for AnyProvider

[bug-ops]

5th recurrence confirmed — landed in the same PR that closed the 4th

PR #6036 (commit beb040a) closed #6012 by adding hand-written self.inner.<method>(...) forwards to CompressedExecutor (crates/zeph-tools/src/compression/decorator.rs), ToolFilter (crates/zeph-tools/src/tool_filter.rs), and Arc<ShellExecutor> (crates/zeph-tools/src/shell/mod.rs) — plus regression tests using the same "stub inner executor returns a distinguishable non-default value" pattern established in #5930/#6011.

This is another one-off manual patch, not the systemic fix proposed here. Neither option was adopted:

• Option A (delegation macro): no ambassador (or equivalent) dependency was added; no Cargo.toml change in the PR. Forwards are still written by hand per wrapper.
• Option B (remove defaults for risk-bearing methods): crates/zeph-tools/src/executor.rs:676 ToolExecutor trait still gives requires_confirmation, checkpoint_undo/checkpoint_redo/checkpoint_list, is_tool_speculatable, and execute_tool_call_confirmed permissive default bodies (confirmed at lines 733-820). No compile-time forcing function was introduced.

So the fix shape is identical to #5930/#6011/#5998: find the wrappers missing forwards this cycle, hand-patch them, add tests. This is the 5th grouped occurrence in roughly two months, and notably the recurrence didn't even wait for a new PR cycle — it happened in the very commit that closed #6012, the issue whose own "needed same-day amendment" was cited in this issue's original impact statement as evidence the manual-audit approach doesn't scale.

Verification performed (2026-07-11, CI cycle 1350)

Re-enumerated every production impl ToolExecutor for site in the workspace. All six pre-existing wrapper impls (PolicyGateExecutor, TrustGateExecutor, AdversarialPolicyGateExecutor, ScopedToolExecutor, ShadowProbeExecutor, CompositeExecutor) plus the three fixed in #6036 plus DynExecutor (crates/zeph-tools/src/executor.rs:981, the type-erased wrapper) now forward all cross-cutting methods. Zero forwarding gaps remain today — but that was also true after #5930, after #6011, and after #5998, each time until the next cross-cutting method or wrapper was added.

Recommend bumping priority given the pattern is now demonstrably not self-correcting even under active review pressure — the same reviewer/session that produced #6012 did not escalate to the architectural fix when landing its own patch a cycle later.

[bug-ops]

Option B, fully specified — ready to implement (CI cycle 1352)

Enumerated every impl ToolExecutor for site in the workspace and verified, per-method, what each already overrides vs. relies on the trait default. This corrects the risk-bearing method list and gives an exact, mechanical diff plan.

1. Corrected risk-bearing subset (10 methods, not 6)

Re-checked all four historical fix commits (38ff5902 #5930, 2f1b75fd #6011, 51683ec1 #5998, beb040aa #6036) for exactly which trait methods were added at each site. The issue body's Option B proposal listed 6 methods; the actual recurring defect history covers 10:

Method	Current default	Caused a fix in
requires_confirmation	false	#5930, #6011, #6036
checkpoint_undo	unsupported()	#5930, #5998, #6036
checkpoint_redo	unsupported()	#5930, #5998, #6036
checkpoint_list	::default()	#5930, #5998, #6036
is_tool_speculatable	false	#6011, #6036
execute_tool_call_confirmed	delegates to execute_tool_call (re-triggers the wrapper's own gate instead of the inner's)	#6011, #6036
is_tool_retryable	false	#6036
set_effective_trust	no-op	#6036
set_skill_env	no-op	#6036
execute_confirmed	delegates to execute (same re-trigger issue as above)	#6036

tool_definitions (default vec![]) and execute_tool_call (default Ok(None)) are not in this set — a wrapper that forgets to override these produces an immediately, obviously broken feature (tool never appears in the schema, or every call silently no-ops) that any smoke test catches. The 10 methods above are dangerous specifically because their default value is a plausible-looking result that silently drops a cross-cutting concern (security gate, audit, checkpoint state, env injection) without any functional symptom.

2. Exact trait diff

crates/zeph-tools/src/executor.rs:676-823, remove the { ... } body and terminate with ; for the 10 methods above; leave tool_definitions/execute_tool_call untouched:

pub trait ToolExecutor: Send + Sync {
    fn execute(&self, response: &str) -> impl Future<Output = Result<Option<ToolOutput>, ToolError>> + Send;

    // was: default `{ self.execute(response) }` — now required
    fn execute_confirmed(&self, response: &str) -> impl Future<Output = Result<Option<ToolOutput>, ToolError>> + Send;

    fn tool_definitions(&self) -> Vec<crate::registry::ToolDef> { vec![] } // unchanged

    fn execute_tool_call(&self, _call: &ToolCall) -> impl Future<Output = Result<Option<ToolOutput>, ToolError>> + Send {
        std::future::ready(Ok(None))
    } // unchanged

    // was: default `{ self.execute_tool_call(call) }` — now required
    fn execute_tool_call_confirmed(&self, call: &ToolCall) -> impl Future<Output = Result<Option<ToolOutput>, ToolError>> + Send;

    // was: default no-op — now required
    fn set_skill_env(&self, _env: Option<std::collections::HashMap<String, String>>);

    // was: default no-op — now required
    fn set_effective_trust(&self, _level: crate::SkillTrustLevel);

    // was: default `false` — now required
    fn is_tool_retryable(&self, _tool_id: &str) -> bool;

    // was: default `CheckpointActionResult::unsupported()` — now required
    fn checkpoint_undo(&self, _n: usize) -> CheckpointActionResult;

    // was: default `CheckpointActionResult::unsupported()` — now required
    fn checkpoint_redo(&self) -> CheckpointActionResult;

    // was: default `CheckpointListResult::default()` — now required
    fn checkpoint_list(&self) -> CheckpointListResult;

    // was: default `false` — now required
    fn is_tool_speculatable(&self, _tool_id: &str) -> bool;

    // was: default `false` — now required
    fn requires_confirmation(&self, _call: &ToolCall) -> bool;
}

Doc comments explaining each method's contract (kept from the current trait) should move to the trait-level # Contract docs rather than being lost, since the per-method "default: X" doc lines no longer apply.

3. Every impl site, current state, required action

Verified by reading each impl block directly (not just grepping method names). 26 production non-test sites, split 10 complete / 1 broken / 15 need mechanical stubs, plus 3 more behind feature = "bench", plus 3 doctest examples, plus ~68 test-only mock structs.

Wrapper/decorator sites — already forward all 10 methods, zero changes needed (verified line-by-line):

Site	File
AdversarialPolicyGateExecutor<T>	crates/zeph-tools/src/adversarial_gate.rs:186
ToolFilter<E>	crates/zeph-tools/src/tool_filter.rs:25
ScopedToolExecutor<E>	crates/zeph-tools/src/scope.rs:462
ShadowProbeExecutor<T>	crates/zeph-tools/src/shadow_probe.rs:205
PolicyGateExecutor<T>	crates/zeph-tools/src/policy_gate.rs:285
TrustGateExecutor<T>	crates/zeph-tools/src/trust_gate.rs:196
CompressedExecutor<E>	crates/zeph-tools/src/compression/decorator.rs:98
CompositeExecutor<A, B> (dual-inner, OR/first-match forwarding — correctly excluded from Option A's delegate-macro fit, but already fully hand-forwards under Option B)	crates/zeph-tools/src/composite.rs:47
Arc<ShellExecutor> (shadow-impl, forwards via self.as_ref().<method>())	crates/zeph-tools/src/shell/mod.rs:1709
DynExecutor (type-erased wrapper over Arc<dyn ErasedToolExecutor>)	crates/zeph-tools/src/executor.rs:981

New finding — live latent instance of the exact defect class, previously undetected:

DynSchedulerExecutor (src/scheduler_executor.rs:522, pub(crate) struct DynSchedulerExecutor(pub(crate) Arc<SchedulerExecutor>), gated #[cfg(feature = "acp")]) only forwards execute, tool_definitions, execute_tool_call — the exact same "Arc<T> shadow-impl" shape that caused #5985/#5998 for Arc<ShellExecutor>. It is not currently a live bug — SchedulerExecutor itself doesn't override any of the 10 risk-bearing methods either, so both sides currently agree on the trait default — but it is a real, previously-unaudited instance of the pattern, hidden because the file wasn't in scope of any of the 4 prior fix PRs (none of which touched zeph-scheduler/scheduler_executor.rs) and because it's feature-gated so a default cargo build doesn't even compile it. This is itself evidence for the "manual audit doesn't scale" argument in the issue body: the CI-1350 verification comment claimed "zero forwarding gaps remain today" and missed this one. Required fix:

impl ToolExecutor for DynSchedulerExecutor {
    async fn execute(&self, response: &str) -> Result<Option<ToolOutput>, ToolError> {
        self.0.execute(response).await
    }
    async fn execute_confirmed(&self, response: &str) -> Result<Option<ToolOutput>, ToolError> {
        self.0.execute_confirmed(response).await
    }
    fn tool_definitions(&self) -> Vec<ToolDef> { self.0.tool_definitions() }
    async fn execute_tool_call(&self, call: &ToolCall) -> Result<Option<ToolOutput>, ToolError> {
        self.0.execute_tool_call(call).await
    }
    async fn execute_tool_call_confirmed(&self, call: &ToolCall) -> Result<Option<ToolOutput>, ToolError> {
        self.0.execute_tool_call_confirmed(call).await
    }
    fn set_skill_env(&self, env: Option<std::collections::HashMap<String, String>>) {
        self.0.set_skill_env(env);
    }
    fn set_effective_trust(&self, level: crate::SkillTrustLevel) { self.0.set_effective_trust(level); }
    fn is_tool_retryable(&self, tool_id: &str) -> bool { self.0.is_tool_retryable(tool_id) }
    fn is_tool_speculatable(&self, tool_id: &str) -> bool { self.0.is_tool_speculatable(tool_id) }
    fn requires_confirmation(&self, call: &ToolCall) -> bool { self.0.requires_confirmation(call) }
    fn checkpoint_undo(&self, n: usize) -> CheckpointActionResult { self.0.checkpoint_undo(n) }
    fn checkpoint_redo(&self) -> CheckpointActionResult { self.0.checkpoint_redo() }
    fn checkpoint_list(&self) -> CheckpointListResult { self.0.checkpoint_list() }
}

Leaf/terminal sites — need trivial stub bodies added (mechanical, matches current default behavior exactly, zero functional change):

Site	File	Methods currently missing (need trivial stub)
DiagnosticsExecutor	crates/zeph-tools/src/diagnostics.rs:111	all 10
ModerationExecutor<B>	crates/zeph-tools/src/moderation.rs:181	9 (already has requires_confirmation)
SetCwdExecutor	crates/zeph-tools/src/cwd.rs:38	9 (already has is_tool_retryable)
WebScrapeExecutor	crates/zeph-tools/src/scrape.rs:235	9 (already has is_tool_retryable)
SearchCodeExecutor	crates/zeph-tools/src/search_code.rs:463	all 10
FileExecutor	crates/zeph-tools/src/file.rs:645	all 10
ShellExecutor (leaf, wrapped by Arc<ShellExecutor> above for all production wiring)	crates/zeph-tools/src/shell/mod.rs:1766	6: execute_confirmed, execute_tool_call_confirmed, is_tool_retryable, is_tool_speculatable, requires_confirmation, set_effective_trust (already has the checkpoint trio + set_skill_env)
McpToolExecutor	crates/zeph-mcp/src/executor.rs:75	all 10
MemoryToolExecutor	crates/zeph-core/src/memory_tools.rs:90	all 10
SkillInvokeExecutor	crates/zeph-core/src/skill_invoker.rs:168	all 10
SkillLoaderExecutor	crates/zeph-core/src/skill_loader.rs:35	all 10
OverflowToolExecutor	crates/zeph-core/src/overflow_tools.rs:39	all 10
IndexMcpServer	crates/zeph-index/src/mcp_server.rs:404	9 (already has is_tool_retryable)
SchedulerExecutor	src/scheduler_executor.rs:440	all 10
MockMcpServer (pub testing helper, crates/zeph-mcp/src/testing.rs, not #[cfg(test)] — unconditionally compiled via pub mod testing;)	crates/zeph-mcp/src/testing.rs:118	all 10
NoopExecutor (feature = "bench")	crates/zeph-bench/src/runner.rs:150	all 10
RetailEnv (feature = "bench")	crates/zeph-bench/src/loaders/tau2_bench/envs/retail.rs:214	all 10
AirlineEnv (feature = "bench")	crates/zeph-bench/src/loaders/tau2_bench/envs/airline.rs:195	all 10

Each trivial stub is one of:

fn requires_confirmation(&self, _call: &ToolCall) -> bool { false }
fn is_tool_speculatable(&self, _tool_id: &str) -> bool { false }
fn is_tool_retryable(&self, _tool_id: &str) -> bool { false }
fn checkpoint_undo(&self, _n: usize) -> CheckpointActionResult { CheckpointActionResult::unsupported() }
fn checkpoint_redo(&self) -> CheckpointActionResult { CheckpointActionResult::unsupported() }
fn checkpoint_list(&self) -> CheckpointListResult { CheckpointListResult::default() }
fn set_skill_env(&self, _env: Option<std::collections::HashMap<String, String>>) {}
fn set_effective_trust(&self, _level: SkillTrustLevel) {}
async fn execute_confirmed(&self, response: &str) -> Result<Option<ToolOutput>, ToolError> { self.execute(response).await }
async fn execute_tool_call_confirmed(&self, call: &ToolCall) -> Result<Option<ToolOutput>, ToolError> { self.execute_tool_call(call).await }

4. Doctest examples that will fail to compile

Three # Examples doctests implement ToolExecutor with only execute/execute_tool_call overridden and must gain the same trivial stubs or cargo test --doc -p zeph-tools breaks:

• crates/zeph-tools/src/executor.rs:627 (EchoExecutor)
• crates/zeph-tools/src/executor.rs:800 (ReadOnlyExecutor — already overrides is_tool_speculatable, needs the other 9)
• crates/zeph-tools/src/scope.rs:342 (MockExecutor)

5. Test-mock migration — the actual hidden complexity

Total impl ToolExecutor for sites in the workspace: 100 (regenerate via grep -rn "impl ToolExecutor for\|impl<.*> ToolExecutor for" crates/ src/ --include="*.rs"). Of these, 26 are production (above) + 3 bench-gated + 3 doctests = 32; the remaining ~68 are test-only mock structs inside #[cfg(test)] mod tests blocks across ~18 files (adversarial_gate.rs, executor.rs, tool_filter.rs, scope.rs, shadow_probe.rs, policy_gate.rs, composite.rs, trust_gate.rs, compression/decorator.rs, crates/zeph-core/tests/turn_lifecycle.rs, crates/zeph-core/src/agent/tests/agent_tests/common.rs, crates/zeph-core/src/agent/speculative/stream_drainer.rs (6 mocks), crates/zeph-core/src/agent/speculative/mod.rs, src/runner.rs, src/acp.rs, src/agent_setup.rs, src/daemon.rs, src/scheduler.rs).

Every one of these needs the same 10-line trivial-stub treatment, purely mechanical (compiler error[E0046]: missing trait items pinpoints each site exactly, no ambiguity in what to write). This is not a design risk — it's a wide, shallow, compiler-driven migration — but it means the real diff is closer to ~100 sites / ~700-900 lines of boilerplate, not the "~10-13 wrapper sites" scope implied by prior cycles' framing. A future mitigation worth a separate, lower-priority issue: a small macro_rules! (e.g. stub_tool_executor_defaults!(MyMock)) that test authors can invoke to get all 10 trivial bodies in one line, reducing the ongoing (not one-time) boilerplate cost for every new test mock going forward. Not proposing it as part of this fix to keep the PR mechanical and reviewable.

6. Complexity / semver assessment

• zeph-tools has publish.workspace = true (published crate) and the workspace is at 0.22.0, pre-1.0.0. Per this project's own convention ("Before v1.0.0: do not worry about backward compatibility — write clean code... Document all breaking changes in CHANGELOG.md"), this is an acceptable breaking change to a public trait; no deprecation shim needed. Must be logged under CHANGELOG.md [Unreleased] as BREAKING CHANGE: ToolExecutor no longer provides default bodies for requires_confirmation/checkpoint_*/is_tool_speculatable/is_tool_retryable/set_effective_trust/set_skill_env/execute_confirmed/execute_tool_call_confirmed — implementors must now be explicit.
• Genuinely small and mechanical for the 26 production + 3 bench-gated sites (29 total, ~1-2 hours, compiler-error-driven, one real behavior fix at DynSchedulerExecutor).
• Wider than initially scoped once test mocks are included (100 sites total) — still mechanical and low-regression-risk (every stub matches pre-existing default behavior exactly, so no test assertions change), but should be budgeted as a full PR cycle, not a "quick fix," and reviewed with git diff --stat sanity-checked against "every hunk is either the trait definition or a 10-line stub block" before merge.
• No external consumers outside this workspace are known to depend on ToolExecutor (no crates.io reverse-dependency signal found), so the practical blast radius is fully contained to this repo.

Recommendation: implement Option B in the next /rust-team session as a single PR: (1) trait diff, (2) DynSchedulerExecutor real fix + regression test using the same "stub inner executor returns a distinguishable non-default value" pattern from #5930/#6011/#6036, (3) mechanical stub pass over the other 28 production/bench sites + 3 doctests + ~68 test mocks, (4) CHANGELOG breaking-change entry. This closes #6019 permanently — no future wrapper or mock can silently inherit a wrong default again, because the compiler forces an explicit choice at every site.