feat: log where each solve spent its clock

[andig]

Why

The p95 regression after the tie-break reserve deploy was diagnosed by reading code, not by measurement: the access log only carries the total response time, and the slow-request dump only catches requests that already exhausted the limit. Nothing in production says how the clock splits between probe, cost stage and tie break.

What

One JSON line per request on stdout, which Container Apps ships to Log Analytics:

{"solve": {"elapsed": 1.62, "stages": {"build": 0.21, "cost": 0.83, "tie_break": 0.55}, "path": "split", "preferences": "LP Optimal, MILP Optimal", "status": "Optimal", "steps": 245}}

• Optimizer.stage_seconds: wall clock per stage via a small contextmanager around the existing solve calls. Accumulates rather than assigns - the tie break is two solves (LP floor, MILP proper) under one name. An absent stage is an absent key, not a zero, so a joint solve is distinguishable from a split that ran out of clock.
• app.py: prints the line after solve(), mirroring the dump_slow_request style.

Per-stage percentiles split by solve path are then a KQL query over ContainerAppConsoleLogs. Ingestion cost is ~50 MB/day at current traffic.

Skipped: Prometheus endpoint (no scraper in Container Apps), sampling (volume trivial), settings toggle (add only if ingestion cost ever bites).

Stacked on #140, so the diff shows only this change.

🤖 Generated with Claude Code