compile-smoke blocks every release: auto-optimize rebuilds stdlib without the ext wrappers, breaking tokio unification

[proggeramlug]

Symptom

compile-smoke fails the full tier — and therefore blocks every release cut,
since it is in full-suite-gate's needs and the job exits on FAIL -gt 0
with no allowlist.

Compile smoke: 1359 passed, 2 failed, 67 skipped
Compile failures:
- test_issue_340_axios_response_props
- test_issue_414_mysql_query_params

Both fail with the tokio-coherence refusal:

the wrapper archive(s) below bundle a DIFFERENT tokio compilation than the
stdlib archive they would be linked with.
  target/perry-auto-0d6ac88f8bb5b6eb/release/libperry_stdlib.a bundles tokio-e69c74b77ea3bbaf
  libperry_ext_mysql2.a                                        bundles tokio-aa3a849219b7b42b

Root cause

crates/perry/src/commands/compile/optimized_libs/driver.rs:846-857 rebuilds
only the two static wrappers, with default features off:

.arg("build").arg("--release")
.arg("-p").arg("perry-runtime-static")
.arg("-p").arg("perry-stdlib-static")
.arg("--no-default-features");

The ext wrappers are not in that cargo invocation, so tokio's features
resolve differently for them than for the freshly-rebuilt stdlib. Cargo only
unifies a dependency across packages built in the same invocation — which is
precisely what the linker's own error message tells you to do:

fix: build the wrapper(s) in the SAME cargo invocation as the stdlib archive

Why adding crates to CI's build line does not fix it

perry-ext-mysql2 is already in compile-smoke's
cargo build ... -p perry-ext-mysql2 line and still fails. The main build does
unify tokio; auto-optimize's subsequent rebuild into perry-auto-<hash>/
then breaks that coherence. The mismatch is created after the build line has
done its job, so no change to the build line can fix it.

Not a regression

The Aug-31 full tier (run 33372993990) failed the same way —
test_issue_414_mysql_query_params, 1347 passed / 1 failed, same tokio error.
It is now 2 failures because axios joined. This has been blocking releases for
at least that long.

Fix direction (needs an owner's judgement)

Auto-optimize's rebuild has to produce archives coherent with the ext wrappers
it will be linked against. Roughly either:

1. include the ext crates that will be linked in the same rebuild invocation, or
2. have auto-optimize rebuild those wrappers too, into its own target dir, or
3. detect the mismatch earlier and fall back to the main-target stdlib.

(1) is what the error message advises, but --no-default-features looks
deliberate — the point of the auto-optimized stdlib is to be minimal — so
naively widening the invocation risks changing what auto-optimize emits. That
trade is a call for whoever owns this subsystem; CLAUDE.md already documents how
a feature-stripped ext build fails silently (str.replace(re, fn) never firing),
which is the failure mode to avoid here.

Impact beyond CI

If a user's perry compile hits the same path with an ext wrapper, they get the
same refusal. The refusal is correct — the alternative is a binary with two
tokio::runtime::context::CONTEXT thread-locals and "there is no reactor
running" at runtime (#507, #7629) — but it means auto-optimize plus an ext
package is currently unusable in that combination.

[proggeramlug]

Closing: fixed in #9577 (auto-optimized builds key their target directory on the selected shared-Tokio wrapper set, aliases deduplicated, compile-smoke exemptions removed), landed via merge train #9580 on 2026-09-03. Axios and mysql2 fixtures now compile concurrently.