fix(metrics): glm family price ~2.5x under router header prices for glm-5.3

[drewstone]

The glm/zhipu/zai family price in src/metrics.ts is ~2.5x under the router's live price for glm-5.3

FAMILY_PRICING (src/metrics.ts line 34) prices the glm family at:

[/glm|zhipu|zai/, { input: 0.0006, output: 0.0022 }]  // $0.60/M input, $2.20/M output

The Tangle router's own response headers for glm-5.3 (2026-08-15, served-model glm-5.3 via zai) report:

x-tangle-price-input:  0.0000016799999999999998   # $1.68/M input  → 2.8x the catalog
x-tangle-price-output: 0.00000528                 # $5.28/M output → 2.4x the catalog

Live confirmation

The P1 live parity run (tangle-network/agent-runtime#869, 8 cells x 3 shots x 2 arms, all legs glm-5.3) metered 13,777 input + 21,477 output tokens on its multishot arm. runMultishot's catalog estimator (estimateRouterCost fed by this table) reported $0.0498; the same tokens at the router's header prices are $0.1365 — 2.74x. Every affected record honestly said usdSource: 'estimated', so the taint is labeled, but the estimate itself misprices any glm-5.3 budget or Pareto axis it feeds by ~2.5x.

Fix direction

• Update the family entry to the router's current glm-5.3 prices ($1.68/M in, $5.28/M out) — or better, split an exact glm-5.3 row so the family regex stays a coarse fallback.
• The durable version of this bug is a static table drifting under a live router. The router already publishes x-tangle-price-input/output per response; any consumer on the router path can capture measured cost per completion instead of estimating (the graph arm's no-estimate rule shows the honest alternative). Worth a catalog-vs-router drift check wherever the table must stay.