[mremond]

Why

Stored partial-byte bitstrings must remain intact after the writing process exits or collects garbage.

What changed

• Partial-byte bitstrings stored in ETS and persistent_term retain their exact values after writer exit or garbage collection.
• Copying reads remain valid after storage removal, including row updates that copy their contents.
• Equal bitstrings remain interchangeable as keys, and bag tables suppress duplicate rows after copying.

Before and after

Before: The lifetime regression failed in all three native runs because stored bitstrings referenced the writer’s freed memory.

After: Both regressions pass ten native and ten BEAM runs each, preserving the 68-bit and 1602-bit values.

This runtime fix has no graphical view; native API transcripts demonstrate the behavior.

Checked

Live validation: Demonstrated for this version. 6 of 6 scenarios driven live in the product.

Scenario	Result	Evidence
Stored values after writer exit	✅ Passed live	Native reads returned equal 68-bit and 1602-bit values through both storage APIs after the writer exited.
Stored values after writer collection	✅ Passed live	Both storage APIs returned the exact values after the live writer collected garbage; monitored cleanup completed normally.
Exact bytes, bit lengths and ownership	✅ Passed live	Ownership checks preserved bytes and logical bit lengths after releasing source owners; native API output confirmed the exact lengths.
Copied reads after storage removal	✅ Passed live	Native returned values remained equal after table deletion and persistent-term erasure.
Row updates that copy stored values	✅ Passed live	A boxed replacement preserved untouched bitstrings through a full row copy and later table deletion.
Copied keys and duplicate bag rows	✅ Passed live	The native probe retained one bag row; copied-key fixtures and padding/length checks passed.

• Complete local gate: Strict lint passed; 2,179 Rust tests and 494 native fixtures passed, with one ignored test and two external-module skips.
• Independent code and proof review: The reviewer found no remaining issues and verified evidence for all six required local scenarios.

How it was checked

cargo build --release --locked -p nera-runtime; cargo build --release --locked -p nera

cargo clippy --workspace --all-targets --locked -- -D warnings

cargo test --workspace --locked --no-fail-fast

python3 scripts/test-allocator-config.py; python3 scripts/test-stacktrace-order.py, using the matching compiler

nera test -j 1 --timeout 30

Both new fixtures and both focused unit tests passed ten consecutive native runs each; both fixtures also passed ten unchanged OTP 29 runs.

The lifetime fixture also passed with NERA_SCHEDULERS=1.

Direct native storage/key operations printed and asserted all required results; local execution covers macOS arm64.

Risk

Risk above low: Blast radius, medium — ETS and persistent_term share the changed copier and in-memory key serializer.

Full risk assessment

Dimension	Level	Why
Blast radius	medium	ETS and persistent_term share the changed copier and in-memory key serializer.
Behavior	low	Corrects partial-bitstring corruption and preserves value-based key behavior.
Undo	low	Reverting restores prior code; no external data or configuration is migrated.
Evidence	low	All six scenarios have reviewed native evidence and repeated BEAM comparisons.
Sensitivity	low	No sign-ins, secrets or real application data are touched.
Novelty	low	Extends existing bitstring copy and key-serialization paths.
Dependencies	low	No dependencies are added or changed.

Pipeline

Updates from git push no-mistakes

Infinitary checked this version: an independent review that also judged the documents, and live validation the review accepted.