fix(cache): stop shipping an unbounded SSD cache, and prepare the 1x bf16 block path

THE BLOCKER, found by an adversarial UI-parity audit and verified live.

Every fresh and migrated session was running an UNBOUNDED SSD cache while the
UI showed 10%:

  fresh config seeded blockDiskCacheMaxGb: 0
    -> finiteNonNegativeNumber(0) returns 0, NOT undefined  (0 >= 0)
    -> buildArgs' `!= null` guard passes -> emits --block-disk-cache-max-gb 0
    -> engine: `if explicit_gb is not None: return float(explicit_gb)` -> 0.0
    -> BlockDiskStore: "max_size_gb: 0 = unlimited"

Introduced when the seed changed from 10 to 0 on the belief that 0 meant
"unset". It means unlimited. Fixed at five links: buildArgs emits GB only when
> 0; fresh configs seed no GB at all; the v17 migration DELETEs the legacy
value instead of writing 0; adopted sessions no longer hardcode 10GB (they also
stamped the defaults version current, so the migration could never reach them);
and blockDiskCacheMaxPercent was missing from RESTART_REQUIRED_KEYS, so moving
the slider did not even ask for a restart.

Proven in the live app, not in a test -- the argv the panel actually spawned:
  default session : --block-disk-cache-max-percent 10, NO --max-gb
  40GB session    : --block-disk-cache-max-gb 40 --block-disk-cache-max-percent 10

The unit test that "covered" this was green throughout, because every literal
string it grepped was individually correct while the composed result was wrong.
Replaced with block-disk-budget-behaviour.test.ts, which models the decision
chain including engine precedence and fails if 0 is ever emitted.

Also from the audit: CachePanel's three Clear buttons discarded the engine's
`caches`/`skipped`/`busy` response, so a refusal ("blocks_in_use") rendered as
success. Two orphaned GB i18n keys removed across all five locales.

bf16 block serialization: block_disk_store now reinterprets bf16 as its raw
uint16 bits instead of widening to f32, with all 13 restore sites routed
through one _restore_serialized_dtype() helper that handles both on-disk
generations so existing caches still restore. Measured 2.0x (65,608 -> 32,840
bytes, bit-exact incl. 1e30).

This is currently INERT and the commit says so: a controlled A/B on
Qwen3.8-27B-4D (a genuine bf16 family) produced identical output in both arms
because prefix_cache.py:4396 already widened the tensor upstream. That A/B
doubles as the safety proof that the change is behaviour-neutral. The upstream
half is a hot-path refactor needing its own correctness campaign -- documented
in docs/internal/SHIP-GATES-CACHE-DEFAULTS.md G10, not rushed here.

The bf16 lossless test stopped asserting the literal "astype(mx.float32)" and
now round-trips through the store, asserting 1x bytes and bit-exactness plus
backward-compatible restore of older f32 blocks.