Studio: cover the unsigned 64-bit edge of a linked-folder identity - #10606

What this is

Follow-up hardening for the intermittent Uploads (windows-latest) failure in rag-upload-compatibility.yml:

test_reauthorizing_same_path_refreshes_root_identity_and_retains_mappings
assert ('xac8c2fef8c2fb32e', 281474976725560) == (12433365377158722350, 281474976725560)

The assertion itself was already corrected in #10536. This adds the coverage that would have caught it, and the coverage that still would not catch the same class of regression in the two neighbouring code paths.

Diagnosis

linked_folders.root_device and linked_folder_files.device are declared INTEGER, and SQLite's INTEGER is signed 64-bit. os.stat identities are unsigned, so folder_sync._store_identity writes anything above (1 << 63) - 1 as f"x{value:x}" and folder_sync._load_identity decodes it back. That encoding has been there since the feature landed; the failure was a test reading the raw column instead of going through the loader.

Confirmed by exercising it rather than by reading:

• sqlite3 raises OverflowError: Python int too large to convert to SQLite INTEGER for 1 << 63, (1 << 64) - 1 and 12433365377158722350, and stores (1 << 63) - 1 fine.
• _store_identity((12433365377158722350, 281474976725560)) returns exactly ('xac8c2fef8c2fb32e', 281474976725560), byte for byte the value in the CI failure. 0xac8c2fef8c2fb32e == 12433365377158722350.

Why it is intermittent

The workflow pins Python 3.12. Since python/cpython#102149, Windows os.stat reads FILE_ID_INFO, so st_dev is the full 64-bit VolumeSerialNumber and st_ino is the 128-bit FileId. A volume serial is effectively random, so its top bit is set roughly half the time. When it is set, st_dev > (1 << 63) - 1, the column holds hex text and the raw comparison fails; when it is clear, the value fits, the column holds an integer and the same test passes. Both observed instances have the top bit set: 0xac8c2fef8c2fb32e here and 0xb2f8ffc4f8ff84bf in #10536. On Linux and macOS st_dev is small, so the encoding is never reached and the case is invisible. On NTFS the 128-bit file id keeps its index in the low 64 bits, which is why the inode half of the tuple matched while the device half did not.

Who was wrong

The test, not the production code. The stored form is a deliberate, documented encoding whose round trip through _load_identity is lossless across the whole unsigned 64-bit range and beyond, and the column value is an opaque OS token that nothing outside folder_sync interprets. Asserting the raw column against st_dev over-specified the storage representation rather than the contract, which is that the identity read back equals the identity written and still compares equal on the next scan. Changing production code to keep the raw integer readable would mean widening the column to TEXT and rewriting every existing row, which is strictly worse than the flake for a persisted store.

That verdict is only sound because the round trip really is lossless, so this branch proves that instead of assuming it.

What this adds

• test_reauthorizing_encodes_a_root_identity_above_the_sqlite_maximum forces _root_identity to return (0xAC8C2FEF8C2FB32E, 1 << 127) and drives the reauthorize path, which writes root_device through its own UPDATE. It then reconciles once more, because the reconciler reloads that row as the identity to expect. Neither of those two steps had a test that reached the encoding at all on a host whose st_dev is small.
• test_identities_round_trip_across_the_sqlite_integer_boundary parametrises 0, 1, 2**63 - 2, 2**63 - 1, 2**63, 2**63 + 1, 2**64 - 1 and 1 << 127 through a real INTEGER column, and asserts that values SQLite can hold stay integers so rows written by older builds keep loading.
• Assertions now name the half that diverged and what the column actually held, instead of printing a two-element tuple and leaving the reader to spot which end moved.
• The sibling exposure, st_ino, is covered by the same parametrisation and by the existing file-identity case; a 128-bit ReFS file id is included.

Before and after

Mutation differential, whole test_rag_linked_folders.py, control worktree pinned to f452d415edce3dc937b4da1f450ed878151813af:

Three mutations that main does not notice are now caught, and the fourth is caught much more loudly.

Full RAG suite differential, run sequentially against the same pinned control:

• control: 7 failed, 794 passed, 38 skipped
• branch: 7 failed, 803 passed, 38 skipped

The seven are the same test_rag_captioning.py cases on both sides, a missing optional module on this host, unrelated to this change. test_rag_ocr_fallback.py fails to collect identically on both sides for the same reason and was excluded from both runs.

Caveat

This host is Linux. A genuine Windows st_dev cannot be produced here, so the out-of-range identity is simulated by substituting _root_identity, using the exact value from the CI failure. What was actually observed here is the sqlite3 overflow, the encoded form matching the CI string byte for byte, the lossless round trip through a real INTEGER column, and the mutation differential above. What only Windows CI can confirm is that a real runner's volume serial takes the same path end to end and that the previously flaking case is now stable across runs whose serial has its top bit set.