Challenge SQLite storage: accepted follow-ups for the 4.0 challenge rework

[minoneer]

Low-priority findings from the pre-3.5.0 adversarial review of the challenge-progress SQLite storage (#137, hardened in #146). All were consciously accepted for 3.5.0; they should be resolved by — or revisited during — the 4.0 challenge rework, whose ChallengeProgressCache/ChallengeExecutor (catalog branch) replaces the current completion runtime.

• Write-behind cache crash window: a hard server crash (kill -9 / power loss) loses up to ~15 minutes of one island's challenge progress (Guava cache flushes on eviction/shutdown only), and an island reset followed by a crash can resurrect pre-reset progress. Parity with the old YAML storage; the 4.0 ChallengeProgressCache design (write-through on completion) resolves it — verify that property survives the catalog rebase.
• PRAGMA synchronous = NORMAL only applies to the init connection. Operational connections are short-lived per call and run at SQLite's default (FULL) — more durable but slower than intended. Harmless on SSDs; fix when consolidating the connection strategy (worth pairing with a single long-lived connection or small pool in 4.0).
• Pinned sqlite-jdbc is shadowed at runtime. plugin.yml libraries pins 3.51.2.0, but Paper's bundled sqlite-jdbc (3.49.x) wins parent-first classloading, so tests and production run different driver versions. No current code path depends on the difference (the NULL-getObject behavior is identical in both). Options: document, or load/relocate explicitly.
• IslandKey strictness: island names not matching x,z (e.g. admin-created WorldGuard regions in the islands world) throw IllegalArgumentException on async paths (chest interactions, challenge signs) — console noise, no data impact. Consider tolerating/ignoring non-island regions explicitly.
• Unmapped legacy files recovery: the migration leaves unmappable legacy completion files in place and logs a summary (see Harden challenge-progress SQLite storage and legacy migration for 3.5.0 #146). If reports come in, recovery is: map the file to an island manually, then delete the legacy_yaml_import_completed row from data/challenge-progress.db to re-run the idempotent max-merge import — but note a late re-merge can resurrect progress onto islands reset in the meantime.

Refs: #137, #146, #119, #128.