Count the cached tokens instead of throwing them away

The CLI reports cache_creation_input_tokens and cache_read_input_tokens
separately from the fresh input count. The event schema already parsed both,
and usageOf then dropped them on the floor.

That mattered more than it looks. S1 to S4 share one session, so each stage
resumes into the conversation the previous one built and sends most of its
prompt as a cached read. The number this app recorded as a review's input usage
was therefore a small fraction of what the model actually read, and there was no
way to show how much the session chaining saved.

Both counters now reach the stage rows and the review totals. Counted
separately rather than folded into the input count, because a cached read costs
a fraction of a fresh one and adding them together would overstate the price.
The cost figure was always right, because it comes from the CLI's own
total_cost_usd, which already accounts for caching.

The fake CLI now reports non-zero cache counters, because a fixture that only
ever produced zeros could not tell the difference between carrying these
through and dropping them. Mutation checked: restoring the drop fails the test
that follows the counters to the review row.

Caching itself is the CLI's to do. What this app controls is whether
consecutive stages share a session, and they do; the --resume flags that make
it true are already asserted at the command line.

Author: Poolchaos

docs/DECISIONS.md

@@ -567,3 +567,19 @@ verified evidence, in writing, here.
 - 2026-07-31 DECIDED (W6): the SSE stream takes a narrow watcher, not the
   manager. It reads a picture and listens for changes; nothing reachable from a
   route handler should be able to start or cancel a review.
+- 2026-07-31 FIXED: cached tokens are counted. The CLI reports
+  `cache_creation_input_tokens` and `cache_read_input_tokens` separately, the
+  event schema already parsed both, and `usageOf` then dropped them. A chained
+  stage sends most of its prompt as a cached read, so the recorded input count
+  was a small fraction of what the model actually read, and there was no way to
+  show how much the session chaining saved. Both are now carried to the stage
+  rows and the review totals. Counted separately rather than folded into the
+  input count, because a cached read costs a fraction of a fresh one and adding
+  them together would overstate the price.
+- 2026-07-31 NOTED: prompt caching itself is the CLI's, not this app's. What
+  this app controls is whether consecutive stages share a session, and they do:
+  S1 to S4 resume into one conversation, which is what lets the whole
+  accumulated context be a cached read rather than a fresh send. S5 is
+  deliberately excluded and pays full price for its prompt, which is the cost
+  of an independent check and is worth it. The `--resume` flags that make this
+  true are asserted at the command line by the scripted-pipeline test.

drizzle/0006_yellow_phil_sheldon.sql

@@ -0,0 +1,4 @@
+ALTER TABLE `reviews` ADD `usage_cache_creation_tokens` integer DEFAULT 0 NOT NULL;--> statement-breakpoint
+ALTER TABLE `reviews` ADD `usage_cache_read_tokens` integer DEFAULT 0 NOT NULL;--> statement-breakpoint
+ALTER TABLE `stage_executions` ADD `cache_creation_tokens` integer DEFAULT 0 NOT NULL;--> statement-breakpoint
+ALTER TABLE `stage_executions` ADD `cache_read_tokens` integer DEFAULT 0 NOT NULL;