memory: stable dynamic-plugin memory ABI (nxmem) — issue #1186 phase 6

[justinchuby]

Part of #1186 — Phase 6 only.

Adds nxmem, a versioned C ABI that lets a dynamically loaded plugin supply allocator, virtual-backing, and shared-mapping mechanisms to the memory governance stack built in Phases 1–5. Phase 7 (removing the built-in CUDA eager allocator) is not started here.

Base branch is justinchuby-phase-5-process-memory-manager, merged at c65cf036.

Shape

Three new crates, mirroring the existing onnx-runtime-ep-nxrt-{abi,host,testplugin} trio:

crate	role
onnx-runtime-memory-abi	dependency-free #[repr(C)] structs, vtables, versioning, status codes. Also ships include/nxmem_memory_abi.h and examples/minimal_plugin.c.
onnx-runtime-memory-host	loads a cdylib, negotiates, and wraps its vtables in the existing DeviceAllocator / VirtualBacking / SharedMapping traits from onnx-runtime-memory-api.
onnx-runtime-memory-testplugin	a cdylib publishing eight mechanisms, dlopened by the ABI tests.

The governor never learns it is talking to a plugin: the host adapter presents the same Rust traits Phase 1 defined.

Narrative documentation: docs/memory/MEMORY_PLUGIN_ABI.md.

ABI contract

Structs. Every struct is #[repr(C)] and begins with uint32_t struct_size at offset 0, in every version, forever. Growable structs carry uint32_t abi_minor at offset 4. Records: NxmemStatus, NxmemDeviceId, NxmemAllocation, NxmemAllocRequest/Result, NxmemByteRange, NxmemRangeRequest, NxmemReleaseOutcome, NxmemReleaseCompletion, NxmemReclaimRequest, NxmemUnloadReport, NxmemSharedPrefixHandle/CommitRequest/CommitInfo, NxmemHostCallbacks, NxmemOpenRequest, NxmemVersionRange, NxmemNegotiateRequest/Response.

Vtables. NxmemAllocatorFactoryVtable, NxmemAllocatorVtable, NxmemVirtualBackingVtable, NxmemSharedMappingVtable.

Required vs optional. On the allocator vtable, allocate / deallocate / retain / release are required at every level and a vtable missing one is refused. Everything else is a nullable slot; NULL means the capability is absent and surfaces as UnsupportedCapability, never as a silently successful no-op. The host treats a non-NULL capability vtable behind a clear capability flag as a contract violation, not a bonus.

Required exports. NxmemNegotiate, NxmemCreateAllocatorFactories, NxmemQueryUnloadReadiness. All three required — without the third, unload could not be gated at all, so a library missing it is refused at load.

Versioning. Major 1 is a hard gate. Minor 1 current, minor 0 baseline; minor only ever appends. Minor 1 appends exactly one slot, release_allocation, gated by NXMEM_CAP_STRUCTURED_RELEASE.

Negotiation and the clamp rule. NxmemNegotiate fixes a ceiling, not an assignment. Each vtable independently declares in its own abi_minor what it really implements, so one module can ship a current mechanism beside a baseline one. read_prefix is the only supported way to read an untrusted vtable:

1. reject null / misaligned pointers;
2. read struct_size and abi_minor with read_unaligned;
3. reject struct_size below what the level the sender claims requires — a sender contradicting itself is broken, not old;
4. clamp effective_minor = min(declared, negotiated) and rewrite abi_minor to it, so callers need only consult the value they get back;
5. copy min(struct_size, size_of::<Self>()) bytes into a zeroed local;
6. NULL every slot above the effective level.

Step 4 is deliberate and is what makes an older host usable with a newer plugin: a newer struct is a strict superset, so reading only the agreed prefix is sound. Rejecting instead would mean no plugin could ever add a slot without breaking every existing host.

Nothing Rust crosses. No trait object, no Arc, no Rust enum layout, no String/Vec, no allocator ownership. Errors are NxmemStatus — a stable u32 code plus a 256-byte inline message buffer, inline precisely so neither side frees the other's heap. Every extern "C" body on both sides is wrapped in catch_unwind (catch_status_panic / catch_void_panic), so a panic becomes InternalError rather than unwinding into foreign frames.

Cross-provider misuse. Every allocation, range, and shared-prefix call carries mechanism_id + device and is checked before anything is touched (WrongMechanism / WrongDevice). allocation_id is a host-assigned monotonic counter and is never pointer-derived — the same reasoning that kept AllocationGeneration non-pointer-derived in Phase 1, so address reuse cannot make one allocation impersonate another.

Ownership and lifetimes

object	created by	released by
factory vtable	NxmemCreateAllocatorFactories	host, via factory release, exactly once
allocator vtable	factory open_allocator	host, via allocator release; retain adds a reference
virtual-backing / shared-mapping vtable	plugin	the owning allocator — never separately by the host
allocation	allocate	deallocate or release_allocation
shared prefix	create_shared_prefix	matching release_shared_prefix
host callbacks	host	host, after the last allocator and the last queued release retire

Every in-pointer is borrowed for the call only, with two stated exceptions: NxmemOpenRequest::callbacks is borrowed for the allocator's whole lifetime, and a factory's name must outlive the factory.

If the host refuses a vtable that open_allocator returned Ok for, it still owes the plugin a release; abandon_allocator re-reads the prefix defensively and calls release only when the struct is well-formed enough to locate that slot. Correspondingly, a plugin publishing a malformed vtable must not allocate state first — the test plugin's short-struct mechanism returns a stateless static, which is what a plugin built against a mismatched header would actually do.

Release outcomes are three non-interchangeable states: COMPLETE (credit unmapped_bytes), QUARANTINED (plugin keeps residual_owned_bytes; address never reissued, residue never refunded), FAILED (nothing mutated; allocation as live as the caller left it). An unrecognised state is treated as quarantine — the only reading that can corrupt neither memory nor accounting.

Threading, re-entrancy, callbacks

Every slot may be called concurrently; a plugin does its own locking.

No participant blocks, and no participant holds its own lock, across a call into the other side.

• The host never calls into a plugin while holding a governance lock. This is the Phase 1–5 rule for trait objects (pressure drops the lock before on_pressure; allocate_with holds no lock while running the caller's closure; run_drain_callback_if_ready uses .take()), tightened rather than relaxed, because an ABI call into foreign code is strictly more dangerous than a trait-object call.
• take_allocation locks the live map, removes the record, drops the guard, and only then enters the plugin.
• A plugin must not hold a lock across request_reclaim: the host may re-enter the same plugin on the same thread to satisfy it.
• drain_releases calls release_completed per retired ticket in enqueue order; take the batch under your lock, drop it, then call the host. The test plugin does exactly this.

Unload gating

NxmemQueryUnloadReadiness reports live allocators, allocations, views, capabilities, and queued releases. MemoryPlugin::try_unload queries the plugin's report unconditionally, before checking its own counters, so a rejection always carries both sides' tallies and a misreporting plugin is visible rather than fatal. Unload is refused while any count is non-zero.

Deferred release keeps everything pinned: an enqueued release counts as live, pins the allocator, which pins the module, and keeps the host's callback table alive because release_completed will still be called through it. enqueue_release increments the module's queued counter before the ABI call.

Field-ordering decisions (drop order is load-bearing)

• PluginModule.library is declared last, so the dlclose happens after every other field has dropped.
• PluginAllocator declares its capability views before core, so views drop first; each view holds its own Arc<AllocatorCore>.
• AllocatorCore.bridge and .callbacks are Boxes created before open_allocator (stable heap addresses) and are still alive when Drop for AllocatorCore calls the plugin's release.
• No Arc cycle: HostBridge owns its counters directly rather than pointing back at the allocator.

No field was added to ScopedMemoryBinding, CudaMemoryBinding, or CudaExecutionProvider — nothing outside the three new crates changes.

Test plugin and coverage

onnx-runtime-memory-testplugin is a cdylib loaded at runtime — out-of-tree in the way that matters (dlopen, no workspace linking) and in-tree in the way that doesn't (built and linted with everything else). It publishes eight named mechanisms rather than switching on env vars or globals, so tests select behaviour by name. It uses host memory only, so the suite is fully portable.

mechanism	what it exists to test
eager	the minimal conforming mechanism: required slots only
lazy	virtual backing, shared mapping, deferred release, structured release
short-struct	a vtable claiming fewer bytes than the baseline prefix
callback-probe	calls request_reclaim; fails cleanly when the host refuses
legacy-1-0	built to minor 0 — an older participant under a newer host
quarantining	keeps residual ownership on release
future-state	reports a release state from a later contract level
sticky	never retires a queued release, so unload stays refused

Required scenarios → tests:

required scenario	test
version mismatch	a_plugin_outside_the_hosts_major_range_is_refused, plus 11 negotiation unit tests
short struct	a_short_allocator_vtable_is_refused_before_any_slot_is_read, a_vtable_smaller_than_the_level_it_claims_is_refused
missing optional capability	a_mechanism_without_optional_capabilities_reports_none, a_host_with_no_reclaim_hook_reports_the_capability_as_absent
allocation / free	allocate_and_release_round_trips_through_the_boundary, a_release_that_misdescribes_the_allocation_is_refused, releasing_an_unknown_address_fails_rather_than_guessing, a_partial_release_is_quarantined_rather_than_refunded, a_release_state_from_the_future_is_quarantined_not_guessed
lazy backing	lazy_backing_commits_decommits_and_reports_mapped_bytes, a_shared_prefix_is_reference_counted_and_costed_once
release ordering	deferred_releases_retire_in_order_and_pin_the_module
callback failure	a_refusing_host_callback_fails_the_allocation_cleanly
unload with live objects	unload_is_refused_while_an_allocator_is_open / …_an_allocation_is_live / …_a_shared_prefix_is_held / …_a_queued_release_has_not_retired, an_idle_plugin_unloads
older participant, newer host	a_minor_0_mechanism_works_under_a_minor_1_host (plugin older) and an_older_host_range_still_drives_the_current_plugin (host older)
cross-provider misuse	an_allocation_cannot_be_released_by_a_sibling_mechanism, an_object_from_another_mechanism_is_refused
factory ownership	every_factory_is_released_exactly_once
public header / C example	header_layout_matches_the_rust_definitions, nxmem_c_example_compiles, a_c_compiler_agrees_with_the_rust_layouts

Three test-design notes, since they affect whether the tests defend their names:

• Everything routes through the real production entry point. The quarantine and future-state tests drive DeviceAllocator::release, not the private outcome-interpreting helper, because the branch worth pinning is the one the production caller actually reaches.
• Module live-object counters are process-wide, which is correct — unload is a process-wide act. So every test in nxmem_abi.rs takes a serialising mutex guard declared as its first statement (guard declared first ⇒ dropped last), and the one test that permanently poisons those counters (sticky never retires its queue — that is the behaviour under test) lives in its own integration-test binary, nxmem_abi_unload_gate.rs, because each tests/*.rs is a separate process.
• The .dylib is rebuilt unconditionally. Cargo builds only the rlib target of a dev-dependency, so the cdylib on disk goes stale silently; the helper runs cargo build -p onnx-runtime-memory-testplugin once per test process and panics loudly on failure. Similarly, every_factory_is_released_exactly_once reads the count out of the loaded module through a test-only exported symbol — reading the statically linked rlib's copy of the same static would observe a different variable and pass while proving nothing. (That was a real bug caught during development.)

The C header carries machine-readable layout annotations that are checked three ways: against Rust size_of, against a generated _Static_assert translation unit compiled by a real C compiler, and by compiling examples/minimal_plugin.c with -Wall -Wextra -Werror against nothing but the header. When no C compiler can be found those tests fail loudly; they never skip silently.

Validation (exact-base comparison)

Base for comparison: origin/justinchuby-phase-5-process-memory-manager @ c65cf036, checked out into a separate worktree and run with identical commands.

Diff vs that base touches only new files plus two purely additive edits: Cargo.toml (3 members, 2 default-members, 3 workspace deps) and Cargo.lock. No existing source file is modified, so no existing package's compilation changes.

cargo test -p onnx-runtime-memory-abi -p onnx-runtime-memory-host -p onnx-runtime-memory-testplugin:

binary	passed	failed	ignored
memory-abi lib	43	0	0
memory-abi header_contract	3	0	0
memory-host lib	9	0	0
memory-host nxmem_abi	24	0	0
memory-host nxmem_abi_unload_gate	1	0	0
memory-testplugin lib	6	0	0
memory-abi doctests	0	0	1
total	86	0	1

The single ignored item is the export_nxmem_plugin! usage doctest, marked ignore because it defines #[no_mangle] entry points that cannot be linked into a doctest binary.

• cargo clippy -p onnx-runtime-memory-abi -p onnx-runtime-memory-host -p onnx-runtime-memory-testplugin --all-targets -- -D warnings — clean.
• cargo fmt --all -- --check: on this branch the only drift is crates/onnx-genai-server/src/routes/completions.rs; the base worktree at c65cf036 reports the same single file. Inherited, untouched, not fixed here.
• cargo doc --no-deps on all three new crates — no warnings. (The known onnx-runtime-memory-governor intra-doc-link warnings are inherited and out of scope.)
• No GPU-gated test was added, executed, or silently skipped. Nothing in these crates has a gpu-tests feature; the whole suite runs on host memory.

Other known pre-existing failures on this stack — matmul_nbits_marlin_numerics, Windows CUDA unnecessary_unwrap, macOS MLAS, governor rustdoc links — are untouched and unrelated to these files.

Acceptance criteria not fully met

CUDA-specific paths are not exercised — there are none in this change, and none were added. This host is macOS/arm64 with no CUDA hardware. Nothing under crates/onnx-runtime-ep-cuda or crates/onnx-runtime-cuda-memory is modified by this PR, so there is no CUDA path here that was "compile-checked only": there is no CUDA path here at all. Wiring a CUDA mechanism behind this ABI is Phase 7 work. Stating it plainly rather than implying GPU coverage.

Every other acceptance criterion in the Phase 6 section of #1186 is implemented and tested.

Non-goals honoured

No internal policy, holder, victim-selection, or governor type is exposed through the C ABI. No compatibility is promised for anything predating this contract — stated in the crate docs and the header.

---

Do not merge, do not enable auto-merge, do not enqueue. This PR stays open for human review, like every PR in the #1186 memory stack.

[codecov]

Codecov Report

❌ Patch coverage is 77.66388% with 828 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.28%. Comparing base (c65cf03) to head (03faeeb).

Files with missing lines	Patch %	Lines
crates/onnx-runtime-memory-host/src/allocator.rs	66.15%	341 Missing and 13 partials ⚠️
crates/onnx-runtime-memory-testplugin/src/lib.rs	73.03%	261 Missing and 20 partials ⚠️
crates/onnx-runtime-memory-host/src/loader.rs	77.16%	75 Missing and 4 partials ⚠️
crates/onnx-runtime-memory-abi/src/vtable.rs	87.86%	47 Missing and 3 partials ⚠️
crates/onnx-runtime-memory-abi/src/version.rs	90.73%	25 Missing and 4 partials ⚠️
crates/onnx-runtime-memory-abi/src/status.rs	87.34%	19 Missing and 1 partial ⚠️
crates/onnx-runtime-memory-abi/src/types.rs	96.92%	9 Missing ⚠️
crates/onnx-runtime-memory-abi/src/lib.rs	85.71%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@                              Coverage Diff                               @@
##           justinchuby-phase-5-process-memory-manager    #1440      +/-   ##
==============================================================================
- Coverage                                       80.01%   79.28%   -0.73%     
==============================================================================
  Files                                             366      373       +7     
  Lines                                          164950   165420     +470     
  Branches                                       164950   165420     +470     
==============================================================================
- Hits                                           131980   131153     -827     
- Misses                                          28150    29421    +1271     
- Partials                                         4820     4846      +26     

Flag	Coverage Δ
mlas	?
offline	79.28% <77.66%> (-0.63%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
crates/onnx-runtime-memory-host/src/error.rs	100.00% <100.00%> (ø)
crates/onnx-runtime-memory-abi/src/lib.rs	85.71% <85.71%> (ø)
crates/onnx-runtime-memory-abi/src/types.rs	96.92% <96.92%> (ø)
crates/onnx-runtime-memory-abi/src/status.rs	87.34% <87.34%> (ø)
crates/onnx-runtime-memory-abi/src/version.rs	90.73% <90.73%> (ø)
crates/onnx-runtime-memory-abi/src/vtable.rs	87.86% <87.86%> (ø)
crates/onnx-runtime-memory-host/src/loader.rs	77.16% <77.16%> (ø)
crates/onnx-runtime-memory-testplugin/src/lib.rs	73.03% <73.03%> (ø)
crates/onnx-runtime-memory-host/src/allocator.rs	66.15% <66.15%> (ø)

... and 17 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

🔴 Benchmark Regression Detected

Comparison of criterion micro-benchmarks: PR head vs merge-base, measured on the same runner in the same job (base first → PR second).

ℹ️ Absolute times are informational only — they vary with runner load. The % change column is the reliable signal because both sides ran under identical conditions.

Status	Scenario	Base	PR	Change
🔴	gather/large_f16_threads=1-internal/131072	11.48 µs	19.08 µs	+66.2%
🔴	gather/large_bf16_threads=1-internal/131072	10.95 µs	17.50 µs	+59.8%
🔴	matmul/large_generic_f32_threads=8/32x1024x1024	4.88 ms	6.81 ms	+39.5%
🔴	add/medium_f16_threads=1-internal/262144	98.58 µs	135.41 µs	+37.4%
🔴	block_quantized_matmul_cached_dense/mxfp4_uncached_dequant_each_call/1x1024x1024	643.14 µs	879.51 µs	+36.8%
🔴	add/large_f32_threads=1-internal/4194304	573.40 µs	762.81 µs	+33.0%
⚠️	matmul/medium_generic_f16_threads=8/32x512x512	33.59 µs	43.56 µs	+29.7%
⚠️	add/medium_f32_threads=1-internal/262144	23.39 µs	29.85 µs	+27.6%
⚠️	gather/medium_f32_threads=1-internal/32768	4.14 µs	5.22 µs	+26.3%
⚠️	tokenization/decode_tokens_per_second	7.11 ms	8.81 ms	+23.9%
⚠️	gather/large_f32_threads=1-internal/131072	36.88 µs	44.81 µs	+21.5%
⚠️	matmul/medium_generic_f32_threads=8/32x512x512	1.06 ms	1.29 ms	+21.0%
⚠️	matmul/large_generic_f16_threads=8/32x1024x1024	104.37 µs	123.57 µs	+18.4%
⚠️	add/small_bf16_threads=1-internal/1024	438.6 ns	514.7 ns	+17.3%
⚠️	add/small_f32_threads=1-internal/1024	180.5 ns	211.7 ns	+17.3%
⚠️	matmul/medium_generic_f16_threads=1/32x512x512	34.66 µs	40.59 µs	+17.1%
✅	reduce_mean/large_f32_threads=1-internal/262144	1.02 ms	1.16 ms	+14.6%
✅	qwen3_sampling_processors/top_k_top_p_full_sort_baseline	5.25 ms	5.99 ms	+14.1%
✅	matmul/large_generic_bf16_threads=8/32x1024x1024	1.79 ms	2.04 ms	+14.1%
✅	matmul/small_generic_f32_threads=1/1x256x256	38.27 µs	43.38 µs	+13.4%
✅	sampling_latency/greedy_per_token	3.72 µs	4.21 µs	+13.1%
✅	add/medium_bf16_threads=1-internal/262144	97.11 µs	109.32 µs	+12.6%
✅	qwen3_sampling_processors/top_k_partial_selection	131.08 µs	146.37 µs	+11.7%
✅	gather/small_bf16_threads=1-internal/4096	506.0 ns	564.7 ns	+11.6%
✅	add/large_f16_threads=1-internal/4194304	1.74 ms	1.93 ms	+11.2%
✅	qwen3_sampling_processors/top_p_fast_after_top_k	484.27 µs	531.89 µs	+9.8%
✅	qwen3_sampling_processors/top_k_top_p_fast	645.46 µs	701.87 µs	+8.7%
✅	add/small_f16_threads=1-internal/1024	432.0 ns	464.1 ns	+7.4%
✅	sampling_latency/top_p_per_token	392.07 µs	412.90 µs	+5.3%
✅	gather/medium_bf16_threads=1-internal/32768	2.36 µs	2.48 µs	+4.8%
✅	qwen3_sampling_processors/top_k_full_sort_baseline	2.13 ms	2.21 ms	+4.2%
✅	qwen3_sampling_processors/top_p_full_sort_after_top_k_baseline	3.25 ms	3.35 ms	+3.2%
✅	kv_cache/alloc_dealloc_pages	38.59 µs	39.76 µs	+3.0%
✅	matmul/small_generic_bf16_threads=8/1x256x256	34.08 µs	34.40 µs	+0.9%
✅	sampling_latency/min_p_per_token	216.05 µs	217.53 µs	+0.7%
✅	matmul/medium_generic_f32_threads=1/32x512x512	2.44 ms	2.44 ms	+0.0%
✅	matmul/small_generic_bf16_threads=1/1x256x256	44.10 µs	43.97 µs	-0.3%
✅	gather/medium_f16_threads=1-internal/32768	2.75 µs	2.74 µs	-0.4%
✅	matmul/large_generic_f16_threads=1/32x1024x1024	91.49 µs	90.87 µs	-0.7%
✅	matmul/small_generic_f16_threads=1/1x256x256	39.17 µs	38.73 µs	-1.1%
✅	reduce_mean/medium_f32_threads=1-internal/65536	258.66 µs	247.64 µs	-4.3%
✅	gather/small_f32_threads=1-internal/4096	786.1 ns	744.7 ns	-5.3%
✅	add/large_bf16_threads=1-internal/4194304	1.85 ms	1.75 ms	-5.5%
✅	sampling_latency/top_k_per_token	61.69 µs	57.90 µs	-6.2%
✅	matmul/medium_generic_bf16_threads=1/32x512x512	637.13 µs	587.79 µs	-7.7%
✅	tokenization/encode_tokens_per_second	462.13 µs	420.24 µs	-9.1%
✅	matmul/large_generic_f32_threads=1/32x1024x1024	10.94 ms	9.94 ms	-9.2%
✅	matmul/medium_generic_bf16_threads=8/32x512x512	693.17 µs	626.18 µs	-9.7%
✅	reduce_mean/small_f32_threads=1-internal/4096	16.54 µs	14.84 µs	-10.3%
✅	block_quantized_moe_cached_dense/mxfp4_uncached_expert_dequant_each_call/rows=1,H=256,I=256,E=4,top_k=1	521.91 µs	466.08 µs	-10.7%
✅	grammar_masking/llguidance_compute_mask/32	86.36 µs	73.46 µs	-14.9%
🟢	matmul/small_generic_f16_threads=8/1x256x256	56.65 µs	46.37 µs	-18.1%
🟢	matmul/small_generic_f32_threads=8/1x256x256	51.24 µs	39.67 µs	-22.6%
🟢	logit_processing/seven_processor_chain_per_step	388.86 µs	294.68 µs	-24.2%
🟢	matmul/large_generic_bf16_threads=1/32x1024x1024	3.10 ms	2.29 ms	-26.2%
🟢	gather/small_f16_threads=1-internal/4096	706.4 ns	515.6 ns	-27.0%
🟢	block_quantized_matmul_cached_dense/mxfp4_cached_dense_repeated_call/1x1024x1024	111.82 µs	77.15 µs	-31.0%
🟢	block_quantized_matmul_cached_dense/mxfp4_preexpanded_dense_oncelock_like_proxy/1x1024x1024	145.41 µs	83.10 µs	-42.9%
🟢	block_quantized_moe_cached_dense/mxfp4_cached_dense_expert_repeated_call/rows=1,H=256,I=256,E=4,top_k=1	133.88 µs	61.84 µs	-53.8%

Visual flags: ⚠️ ≥ 15% slower, 🔴 ≥ 30% slower — calibrated against measured runner noise (~27% worst-case on multi-threaded matmul)

Host info

CPU: Apple M1 (Virtual)
Cores: 3
OS: Darwin 25.5.0 arm64
Rust: rustc 1.97.1 (8bab26f4f 2026-07-14)
Load avg: { 3.60 3.44 4.57 }

What this cannot catch

• Regressions in code paths not covered by these benchmarks (e.g., end-to-end decode with a real model)
• Sub-threshold regressions that compound over multiple PRs
• Performance changes that only manifest under GPU execution
• Latency changes in the ORT integration path (these benchmarks exercise the native Rust kernels)

[justinchuby]

Closing: superseded by #1579, which collapsed phases 1–7 into a single merge — landed as a36964280 (squash, 126 files, +43956 −3286).

This PR was rejected under the lockout rule and superseded by the approved revision that was stacked on top of it (not by a replacement of it). Per #1579's own guidance, it was never meant to be reviewed individually.

Containment verified, not assumed:

$ git merge-base --is-ancestor 03faeebac ebceab071   # ebceab071 = #1579 head
→ ancestor

Every one of the 15 stack heads (#1252 → #1533) is a literal ancestor of the merged head, and I separately confirmed the merged head's content reached main: of the 126 files #1579 touched, exactly one differs from main — crates/onnx-runtime-session/src/executor/tests.rs, where main carries 120 extra lines from #1703 (Expand-broadcast mask tests). That is the conflict resolution correctly preserving the other side, not content loss.

Why this didn't close itself: #1579's body says Closes the stack: #1252 #1263 …, which GitHub does not parse — the closing keyword must be immediately followed by the reference, and in any case closing keywords only ever close issues, never pull requests. So all 15 stayed open by mechanism, not by intent.

#1186 stays open: #1579 explicitly gates it on memory-plugin-provider-wiring (the back half of Phase 6 criterion 8, provider/context pinning), which has not landed.