Fix: a very large numeric annotation permanently broke indexing and queries

[pswies]

What was broken

If anyone saved an entity with a numeric annotation of 2⁶³ or larger (roughly 9.2 quintillion), indexing that entity failed — and the indexer shut down for good. From that moment every arkiv_query on the node timed out with context cancelled, and a restart didn't help: the node re-read the same entity and broke again.

This is what took down query serving on all Braga RPC nodes on 2026-07-03 (the entity had a numeric annotation named big with such a value).

Why it happened

Numeric annotation values are kept in an SQLite column. SQLite stores whole numbers as signed 64-bit, and Go's database library refuses to pass an unsigned 64-bit number too big to fit:

sql: converting argument $2 type: uint64 values with high bit set are not supported

The value was passed straight through, so one big value was a fatal, permanent stop.

The fix

Store the value with its top bit flipped, as a signed number (value XOR 2⁶³). This solves both problems at once:

• No more crash: the stored number always fits the database's signed 64-bit column.
• Ordering stays right for every value: the flipped form grows in exactly the same order as the original number over the whole 0 … 2⁶⁴−1 range, so <, <=, >, >= give correct answers even across the 2⁶³ boundary. (An earlier revision of this PR kept large values misordered; review pushback was correct and this now handles them properly.)
• Exact matches and IN lookups are one-to-one, so they stay exact for every possible value.

Existing databases

A one-time migration (000002) re-encodes the numeric index table automatically the first time a node starts on the new version. Notes for reviewers:

• It rebuilds the table rather than updating in place — the transform swaps the two halves of the number line, so an in-place update could momentarily create duplicate keys.
• The shift constant is written as two steps (± 9223372036854775807 ± 1): the one-step constant 2⁶³ doesn't fit in a 64-bit integer and SQLite would silently switch to floating point, corrupting values. This exact failure was caught by the migration test in this PR.
• Wedged Braga nodes recover on upgrade: they resume from where they stopped, and the previously-fatal entity now indexes fine.
• One-time startup cost proportional to the size of the numeric index table (a table copy).

Tests

• Regression: index an entity with numeric annotations 2⁶³ and 2⁶⁴−1 through the same code path that failed in production; find it again by equality and IN lookup.
• Range ordering across the boundary: entities with values 100, 2⁶³, 2⁶⁴−1 answer <, <=, >, >= correctly in all combinations.
• Migration: build a database exactly as the released version wrote it (schema version 1, raw values), open it with the new code, and verify old rows still answer equality and range queries correctly.

🤖 Generated with Claude Code