2.9.18: Storage cleanup tier 1 — drop bank JSONs, exclude WebView caches, add diagnostics

2.9.18 — Storage cleanup (Tier 1)

This release is the first of a multi-step effort to bring jidoujisho2's
on-disk storage footprint in line with what comparable tools (e.g.
Yomitan) achieve for the same
dictionary data. It contains no functional changes — search, reader,
import, and card creation behave identically. All wins are pure disk
space.

What changed

Bank JSON files are no longer kept after import

Previously, when a Yomichan-format dictionary was imported, its *.json
bank files (the source data already parsed into the database) were
extracted to app_flutter/dictionaryResources/<id>/ and left there
indefinitely. They served no purpose post-import — only image, audio,
and CSS assets referenced via jidoujisho:// URLs are needed at render
time.

After this update:

• New imports delete term_bank_*.json, term_meta_bank_*.json,
  kanji_bank_*.json, kanji_meta_bank_*.json, tag_bank_*.json and
  index.json from the resource directory once the database write
  succeeds.
• A one-time scan at app launch applies the same cleanup to dictionaries
  imported by previous versions, so existing installs benefit without
  requiring re-import.
• Image/audio/CSS assets are preserved.

For typical installs this can free hundreds of megabytes to a few GB
depending on the size of imported dictionaries.

"Clear reader cache" menu item

A new entry in the home-page overflow menu (between Restore data and
Attribution) wipes WebView cache directories used by the ttu Ebook
Reader:

• The Huawei system WebView cache (app_hws_webview/) is cleared in
  full — it is purely a renderer cache.
• Inside app_webview/, only known cache subdirectories (Cache,
  Code Cache, GPU Cache, GPUCache, CacheStorage) are cleared.
  The IndexedDB store containing imported books and reading progress
  is never touched.

A confirmation dialog shows how much space will be freed before
clearing.

Backup excludes WebView caches

AppBackupRestore.createBackup() now skips:

• app_hws_webview/ at the top level
• The cache subdirectories listed above wherever they appear in the
  data tree

Backup ZIPs become significantly smaller and faster to produce. Restore
behaviour is unchanged.

Storage & Benchmark diagnostics dialog

Long-pressing the version label on the home page now opens a developer
diagnostics dialog showing:

• Top-level data directory breakdown (per directory, sorted by size)
• Isar database file size
• Per-dictionary resource directory size, broken down into reclaimable
  bank JSONs vs retained assets
• "Run benchmark" button: samples 100 random heading terms from the
  database and runs searchDictionary on each, reporting min/avg/
  median/p95/p99/max search latency
• "Share" button to send the report via Android's share sheet

This dialog has no localised strings — it is a developer/power-user
tool used for measuring the impact of this and future storage work.

What did not change

• The dictionary database schema is unchanged.
• The search code path is unchanged. No queries were modified.
• The DictionaryEntry.extra field is still present even though it is
  unused — removing it requires regenerating Isar code, which will be
  done together with the larger schema work in a future release.
• No new package dependencies were added.

Coming in subsequent releases

This is part one of a planned three-tier storage optimisation:

• Tier 2 — compress the definitions field of dictionary entries
  using Zstd. Estimated to roughly halve the Isar database size on top
  of Tier 1.
• Tier 3 — schema flattening: drop the DictionaryHeading /
  DictionaryTag link relationships and store entries as flat rows
  with inline term/reading/tag fields, mirroring Yomitan's design.
  Estimated to halve the database size again. Will require re-importing
  all dictionaries.

Each tier ships independently so its impact can be measured.