Add causal profiling (RFC 007) behind --features causal

Instrument the four suspect regions from bench/RPS: cache-lookup,
cache-insert, sqlite-query, and gzip-decode, plus an asset-served
progress point. New `ccc causal` subcommand runs the sweep against
live traffic and prints a summary (optionally a .coz file and a
ledger audit).

Ran it under the same 80/20 hot-set workload as bench/RPS - see
bench/CAUSAL.md for the methodology and results. Findings:

- sqlite-query is the real bottleneck on a cache miss (+20.5% at a
  50% speedup, roughly linear).
- cache-lookup/cache-insert are noise-level (0-4%) - the O(n)
  recency-scan touch() bench/RPS flagged as a possible follow-up is
  not actually costing anything, so that's off the table.
- Switched prepare() -> prepare_cached() on the query as the obvious
  fix; re-measured and it made no real difference (+20.0% -> +20.5%,
  within noise). Kept it anyway (strictly not worse), but it shows
  execution cost (B-tree lookup + BLOB copy) dominates over parse
  cost in that site.
- gzip-decode barely gets exercised since real clients (and oha)
  negotiate gzip - not worth optimizing further.
- Net conclusion: the existing CCC_CACHE_CAPACITY tuning from
  bench/RPS (+42-47% RPS) is the correct lever, and causal profiling
  explains why - every cache hit skips the one site that matters.

Zero cost when the feature is off: causal_site!/progress! compile to
no-ops without smarm-causal.

Cargo.toml

@@ -4,6 +4,12 @@ version = "0.1.0"
 edition = "2024"
 license = "AGPL-3.0-only"
 
+[features]
+# RFC 007 causal profiling in smarm. Off by default (same zero-cost
+# discipline as smarm itself): causal_site!/progress! call sites compile
+# to no-ops without it, and `ccc causal` is unavailable.
+causal = ["smarm/smarm-causal"]
+
 [dependencies]
 urus = { git = "https://git.kalsbeek.dev/Markk116/urus.git", tag = "v0.2.2" }
 # Pinned to the same tag urus itself depends on, so Cargo unifies both