MC 26.3 compatibility and performance: NBT key fix, block-state dictionary, integer time index, batched writes

[Pau1am]

Rebased onto master at 1.3.25. Every change below was measured on a live Fabric
26.3 server against CoreProtect 24.1 on the same machine and the same workload; the
method and raw per-run data are in the accompanying report.

Note on the rebase

Upstream moved while this branch was in flight:

22705ac fix: update block state NBT format for 26.3 (#402)
dd947aa Update modVersion from 1.3.24 to 1.3.25

#402 fixes exactly what this branch's own NBT commit fixed, so that commit has been
dropped and the code is now upstream's - credit belongs there. The one part that was
ours alone, a read-side fallback to the legacy Properties key, was dropped too: on
26.3 writeBlockState emits properties, so the fallback could never fire and was
dead code. This is also why the diff no longer touches NbtUtils.kt.

Storage

• Block-state dictionary encoding. Identical state strings are stored once in a
  block_states table and referenced by integer id. Measured on a stairs workload:
  31.3% smaller (55.8 bytes per row) than repeating the literal state text.
• Integer time index. time is TEXT ('2026-10-05 13:22:21.702', ~23 chars), so
  an index over it cost ~35 bytes per row - 19.6% of the whole database, the largest
  object after the table itself. A new time_ms column (epoch millis) carries the
  index at ~16 bytes: the time index shrinks 54% and the file 7.9% like-for-like.
  Migration is automatic, resumable, and queries fall back to the text column while a
  backfill is still running, so a partially migrated database stays correct.
  /ledger compact reclaims the freed pages.

Performance

• Real JDBC batch insert. batchInsert was emitting one statement per row - a
  13,500-action burst produced 13,500 individual INSERT INTO actions statements.
  Writing through a prepared statement with addBatch/executeBatch, with values
  still produced by Exposed column types via valueToDB so the stored representation
  is unchanged, cut the write window from 1.53 s to 0.62 s of real work
  (drain rate 2,977 -> 3,727 rows/s).
• Burst-aware queue scheduling. The writer paid the full batchDelay on every
  pass even with work already queued, which accounted for 6.1 s of an 8.7 s ingest
  window. It now skips the wait only while the previous pass filled a complete batch,
  and returns to the configured cadence as soon as one comes up short - trickle
  traffic still batches exactly as before.
• Rollback/restore batch 1,000 -> 5,000 rows, halving a 13,500-action rollback
  (4.01 s -> 2.01 s) with zero "can't keep up" warnings at either setting.

Net effect against the pre-optimisation build, medians of three runs:

	before	after	CoreProtect (DuckDB)
write drain rate	2,977 rows/s	3,727 rows/s	3,449 rows/s
rollback (13.5k)	4.01 s	2.01 s	0.21 s
bytes per row	181.4	167.2	107.7

Also evaluated and rejected (measured, not assumed)

• composite (time_ms, id) / (time_ms, rolled_back, id) indexes - still force a
  temp B-tree sort for ORDER BY id DESC LIMIT n, no query gain, +3% file size
• SQLite foreign keys off - 5.9 -> 5.7 ms per 1,000-row transaction (3%), not worth
  the integrity trade
• SQLite page_size - silently ignored once the database exists (every value
  collapsed back to 4,096), so not a usable lever
• dropping the legacy time column - ~13% more space, but needs a table rebuild plus
  a branched read path for a non-reversible migration; not worth it against the
  correctness risk

Verification

Live MC 26.3 Fabric server: zero exceptions, rollback -> restore round-trip preserves
the exact block state (execute if block ... oak_stairs[facing=west,half=top] passes
after restore), both migration paths pass their checks, and every benchmark run logs
exactly 13,500 rows with zero errors. The one style: commit is detekt autocorrect
and can be skipped when reviewing.