QUEUE-148: address follow-up table-store review

[peter-lawrey]

Summary

• wait for a preallocated but unpublished first header instead of reporting corruption
• preserve read-only fallback for an unwritable directory with no metadata file
• retain released recovery-field headers and make legacy 64 KiB read-only mappings observe growth
• emit the canonical STStore alias and require explicit marshallable framing before construction
• classify failures inside persisted SCQMeta as Queue metadata corruption while preserving application metadata failures
• preserve public lock callback Throwable identity and make cleanup suppression identity-safe
• reject the ambiguous zero value marker and refresh record scan bounds after growth
• keep provisional stores reachable until lock cleanup completes

Wire format policy

BINARY_LIGHT is the supported table-store encoding. BINARY remains a legacy selector for the common subset and is decoded with BINARY_LIGHT. READ_ANY is read-only detection only. RAW, fieldless, compressed, and text formats remain unsupported.

Security-focused concerns are explicitly outside this follow-up scope.

Mac build 1828

The supplied log built commit 2309982, not this branch. Its two remediation-test failures were global resource-tracing collisions with a concurrently running test and both passed on rerun. The broader failures were timeouts, disk use, and leaked resources across unrelated tests. The log contains no tryLock IOException evidence, so generic acquisition IOException remains terminal pending supported-platform evidence.

Verification

• 92 focused tests: 0 failures, 0 errors, 0 skipped
• mvn clean verify: 1204 tests, 0 failures, 0 errors, 56 skipped
• git diff --check
• no changed Java line exceeds 144 characters
• every added test method is referenced by a production rationale note; no //! appears in tests

Deliberately deferred

• the pre-existing per-key file-growth behavior
• direct deterministic injection of the post-construction builder cleanup edge
• supported-platform evidence for FileChannel.tryLock IOException classification
• security-focused findings