ValuesPlainKeyReferencingThresholdReached was a parity check
((span)%2 == 0) and MayContainValuesPlainKeyReferencing was a strict-
greater size check (span > 2). Under the old merge planner spans were
always {1, 2, 4, 8, ...}, so the parity test was effectively "merged
file?" — but with clipMergeStartToFileBoundary the planner can now emit
odd spans >= 3, which the parity test misclassifies as plain and the
read path then fails to dereference. The two predicates also disagreed
at span = 2: the write path shortened those files but the integrity
check skipped them.

Replace both bodies with span >= minStepsForReferencing (= 2), matching
the constant's name, and drop MayContainValuesPlainKeyReferencing in
favor of the surviving function. Span-1 files (the only legitimate
plain case) are unchanged; every multi-step file is now consistently
treated as referencing on read, write, and integrity paths.