Two native pg implementations exported the same extern "C" symbols, resolved by link order — audit the perry-ext-*/perry-stdlib pairs and gate duplicate symbol exports

[proggeramlug]

Found while removing the pg native binding (PR #10677): there were two native pg implementations, both
defining the same extern "C" symbols, and link order silently decided which one was live.

• crates/perry-ext-pg/ — the registered binding (sqlx::postgres + tokio via perry-ffi).
• crates/perry-stdlib/src/pg/ — an older duplicate that survived the Native package ecosystem v1: open, extensible, with zero developer-facing change #466 migration behind a bundled-pg
  feature, exporting the same symbols.

Nothing reported this. There is no gate that notices two crates exporting one extern "C" surface; the linker
just picks one. Whichever it picked is what users got, and a fix applied to the other one would have looked
inert — the same failure shape as the stale-archive trap CLAUDE.md documents, but caused by duplication rather
than staleness.

This is probably not unique to pg

mysql2 shows the same two-location shape: crates/perry-stdlib/src/mysql2/ (~1870 lines) alongside a
crates/perry-ext-mysql2 crate. That one is being untangled now as part of its own removal, but the pattern
suggests the #466 migration (moving bindings from perry-stdlib into perry-ext-* crates) left duplicates behind
in more than one place.

There are currently ~38 crates/perry-ext-* crates. Any of them whose package also has a crates/perry-stdlib/src/<pkg>/
directory is a candidate.

Suggested work

1. Enumerate it. For each perry-ext-* crate, check whether a same-named perry-stdlib/src/ module exists, and
   whether the two export overlapping extern "C" symbols.
2. Add a gate. A duplicate #[no_mangle]/extern "C" symbol across crates should be a build or lint failure,
   not a link-order coin flip. This repo already ratchets several similar properties (addr-class, raw-handle,
   unrooted-local-shape), so the machinery exists.
3. Delete the dead side of each pair. Where both are live-ish, decide which is canonical before the removal
   campaign reaches that package — otherwise a removal PR deletes one and leaves the other quietly serving traffic.

Why it matters for the current work

The owner's goal is to delete these hand-written Rust reimplementations in favour of compiling the real npm
packages. A removal that deletes only the registered copy would leave a shadow implementation in the tree that
still claims the symbols — the package would appear to be "removed" while a duplicate continued to answer. #10677
avoided that only because its agent went looking.

[proggeramlug]

Third confirmed instance: axios. The removal PR (#10679) found axios also had two native locations — crates/perry-ext-axios/ and crates/perry-stdlib/src/axios.rs.

So the pattern now holds for every package the removal campaign has touched:

package	locations
pg	perry-ext-pg/ + perry-stdlib/src/pg/ (same extern "C" symbols, link-order resolved)
mysql2	perry-ext-mysql2/ + perry-stdlib/src/mysql2/ (~1870 lines)
axios	perry-ext-axios/ + perry-stdlib/src/axios.rs

Three for three. That is no longer a suspicion about the #466 migration — it is the default state, and the enumeration in step 1 of this issue should be treated as expected-to-find-many rather than exploratory.

One more thing worth folding into the audit, from #10679: removing axios also deleted compiler-level special-casing that existed solely for it — HIR "axios→Response" local-instance tagging across four files, and an emit.rs callable-default case for which axios was the only user. So these bindings are not merely duplicated Rust; some of them have tendrils in HIR and codegen. Any estimate of removal effort that counts only the crate directories will be low.

[proggeramlug]

mysql2's duplicate was worse than pg's, and the removal found a gate blind spot. Both from PR #10680.

On the duplication: pg's two copies were resolved by link order — bad, but at least one consistent implementation won. mysql2's were not equivalent. Both crates/perry-ext-mysql2 and crates/perry-stdlib/src/mysql2/ (~1870 lines, behind perry-stdlib's default-on bundled-mysql2 feature) exported the identical js_mysql2_* symbol names, but registered handles in separate, documented-as-disjoint integer spaces — crates/perry-ffi/src/handle.rs states perry-ffi's and perry-stdlib's common::handle registries are distinct. The stdlib copy's dispatch_mysql2_method/dispatch_mysql2_property fallback (used for Drizzle's interface-typed fields) could therefore only resolve handles it had created itself.

So this was a live footgun in the default build, not dead code: two implementations claiming one symbol surface, with mutually unintelligible handles. Add "do the duplicates share a handle space?" to the audit — symbol collision alone understates the risk.

On the gate blind spot: binding_governance.py --check, binding_pins.mjs --check and every_dispatch_entry_has_manifest_counterpart all passed, and the removal still left dangling references that only grepping found:

• explicit -p perry-ext-mysql2 args in .github/workflows/test.yml
• the same in run_doc_tests.sh and run_doc_tests.ps1
• hardcoded row/provider counts in scripts/native_result_ledger.tsv and .py

None of the binding-registry gates know about build-script or workflow references to a crate. Worth extending the audit in step 1 of this issue to include a plain repo-wide grep for the crate name, and worth considering whether a gate should assert that no -p perry-ext-* argument names a crate absent from the workspace.

[proggeramlug]

Sharper framing of the mysql2 case, from the merge lane, worth stating plainly because my earlier comment undersold it:

Two implementations sharing js_mysql2_* symbol names while using disjoint handle spaces is not dead code — it is a handle from one space being decoded by the other's accessors. That is the same failure family as the is_valid_obj_ptr catch earlier in this campaign: a plausible-looking value handed to the wrong owner's decoder.

And the consequence is worse than a crash. Had that path been exercised, the symptom would be arbitrary field reads, not a clean failure — an integer valid in one registry indexes something unrelated in the other. No guard fires, nothing throws; you get wrong data.

So for the audit in this issue, do the duplicates share a handle space? is not a secondary question. Two copies that share a symbol surface and a handle space are merely redundant. Two that share a symbol surface and have separate spaces are a silent-corruption hazard, and should be triaged ahead of the merely-duplicated ones.