Attribute-sharding admission checks the raw abort-marker config, not the latched native setting #3949

unsupportedResidencyPolicy (resources/residencyPolicy.ts) admits an attribute-sharded table when storage.rocks.transactionLogAbortMarkers resolves to enabled in the current configuration. The native setting is process-global and latched at the first RocksDB config() call (latchAbortMarkers in resources/transactionLogAbortMarkers.ts); a later configuration change takes effect only after a restart.

So a node started with markers explicitly off, whose configuration is then changed to on without a restart, admits an attribute-sharded table while the process still runs without abort markers. That breaks the registration prerequisite the check exists to enforce.

Reachable only with replication.experimentalAttributeSlots enabled.

Fix: check the latched value (latchAbortMarkers(...), or a reader of the latched setting) instead of re-resolving the raw configuration.

Found by a cross-model pre-push review of harper-pro's base-copy liveness change; the check arrived with #3928.

Review-Deferral: 9f2763f3fc03b272 severity=minor category=correctness

🤖 Filed with Claude Code — Claude Opus 5.5