Expose deploy diff budgets and phase timings for CAS-heavy upgrades

[MajorTal]

Context

Kychon tested a full-directory static patch against Eagles to understand why upgrades take longer than expected when almost all content is CAS-reused.

Strict benchmark, no rebuild:

• Input: full dist/ directory passed to the SDK.
• Actual content change: one word in dist/js/env.js.
• Release diff: 1 site path changed, 152 unchanged.
• newly_uploaded_cas_bytes: 331
• reused_cas_bytes: 72,368,346
• deploy.apply: about 5.8s.
• Event timing: plan/diff around 1.3s, commit around 1.3s, ready around 5.8s.

Earlier full fleet upgrades took much longer, and in those cases functions did change. The CAS numbers show static bytes are not the main cost, but the deploy output does not make that obvious enough during normal upgrade operations.

Problem

For CAS-heavy deploys, operators need a clearer answer to: "what actually changed, where did the time go, and is this deploy larger than intended?"

Today we can inspect this after the fact with release diffs and event logs, but it would be useful for the SDK/CLI/deploy API to surface this directly:

• Path counts changed/added/removed/unchanged.
• Newly uploaded bytes versus CAS-reused bytes.
• Function changes by name and code hash.
• Route/migration changes.
• Phase timing breakdown, especially planning, upload/skip, commit, activation/ready.
• Optional guardrails or budgets that can fail/warn when a deploy unexpectedly changes too many paths or functions.

Proposed capability

Add first-class deploy summaries and optional budgets for deploy.apply / CLI deploy flows:

• Print or return a concise diff summary before/after commit.
• Include per-phase duration and byte accounting.
• Support budget inputs such as max changed static paths, max newly uploaded bytes, expected changed functions, or "static-only".
• Make it easy for API-first fleet upgrade automation to attach this summary to its final report.

Why this matters

Kychon wants fleet upgrades to be boring and automatable:

• If a one-word static change uploads only 331 bytes but takes 5.8s, that is probably fine.
• If a rebuild unexpectedly changes 21 pages, the operator should see that immediately.
• If functions changed, the report should make clear that function publish/activation is the likely deploy cost.

This would make Run402's CAS behavior more legible and give downstream fleet automation better safety rails.

[MajorTal]

Triaged as feature request: current main already exposes deploy summary/static asset diff data (path counts and CAS byte reuse), but this issue asks for new budget inputs and phase timing/function hash reporting. Those are product/API contract additions, not an auto-fixable client bug.