gguf-tdf draft-01: reconcile C-R7 and I2 bound with §13.3 reader cache (k cached + decrypt-ahead)

§13.3 "Reader cache size" (draft-01) permits a reader to keep `k` decrypted weight segments and a decrypt-ahead window, with extra plaintext `headerBytes + k·maxSegment` documented when claiming C-R7. But §16 C-R7 (~line 1159) and the §15.4 I2 row (~line 1202) still fix the bound at `headerBytes + maxSegment`.

The reference reader (arkavo-edge `arkavo-gguf-tdf`, PR arkavo-org/arkavo-edge#664) now holds up to `headerBytes + (8 + 4)·maxSegment` — 8 LRU-cached segments plus 4 decrypted ahead on a worker thread (measured: 8.1 s → 4.5 s load on a 3 GB model). Nothing in arkavo-edge claims C-R7 today, so no false claim ships, but C-R7/I2 should either (a) become parametric — "`headerBytes + N·maxSegment` with `N` stated by the implementation, default 1" — or (b) define a separate tier for cached/pipelined readers. §13.3's thread-safety paragraph ("MUST mutex a single weight-segment scratch") also predates the worker design and should describe the ownership model actually used (worker owns its own file handle and encryption instance; results cross a channel as zeroizing buffers).

Raised by the final review of arkavo-edge#664.

Read §13.3, the §15.4 I2 row, and §16 C-R7, then compare their bounds with the reader behavior described in arkavo-edge#664. Reconcile the bound and document the worker ownership and buffer handoff model; done means the requirements are internally consistent and do not make an unclaimed C-R7 assertion.

Written by the indexing model from the issue text.