fix: preserve 哈哈倉頡 source order (#194)

[limeimetw]

Summary

• pin the reporter's final 20260723_082459 哈哈倉頡 source by SHA-256 and row count
• rebuild Database/hahacj.limedb deterministically in source order with zero initial scores
• preserve ,. Lime end keys and add the established custom_idx_code ON custom(code) index
• use the same DEFLATE archive convention as the other downloadable .limedb files
• update Android/iOS catalog metadata to 33,044 mappings and 496 KB
• add a repository-wide source-order contract and PR/release gates for every downloadable .limedb
• retain an Android runtime regression that imports the exact committed archive and verifies sorting-disabled j → 都, 十

No Android or iOS database import/export implementation changes remain in this PR.

Root cause

The #112 archive was generated from a transformed record set rather than directly from source order:

• archive _id order follows output-word order
• score order retains the intended source rank
• sorting-disabled lookup correctly uses _id ASC, exposing 十, 都
• the archive also differs from the submitted source by more than ordering

The corrected archive is rebuilt directly from the reporter-authoritative source, so its IDs carry the intended candidate order.

Verification

• authoritative source hash, version, and 33,044-row count
• repeated rebuilds are byte-identical within one toolchain; committed archive is semantically validated across toolchains
• archive rows equal source rows in _id ASC order
• custom_idx_code ON custom(code) exists
• all scores and base scores start at zero
• PRAGMA integrity_check returns ok
• repository-wide .limedb contract gate passes for all six archives
• Android unit tests pass
• Android test sources compile
• Pixel 9 Pro API 36 exact-archive runtime regression passes: j → 都, 十
• Ponytail review removed speculative platform SQL/tests and aligned the artifact with existing index/compression conventions
• Claude Code review and focused re-review: no blocking findings
• macOS/Xcode XCTest and iPhone/full-iPad/narrow-iPad runtime verification

Existing installations

Updating the app does not replace a 哈哈倉頡 table already downloaded locally. Existing users must remove/re-download 哈哈倉頡 before retesting. The separate one-step table-update feature remains tracked outside this defect.

Fixes #194