feat(desktop,agent): compaction threshold slider, real-occupancy thresholds and live context capacity pins

[complyue]

What

Turns the single compact_ratio knob into four explicit, independently
configurable compaction thresholds (soft / snip / compact / force), exposes
real context occupancy end-to-end, and renders all four as live pins on the
desktop context gauge with a draggable settings slider.

• Agent: compactThresholds() now computes soft/snip/compact/force
  boundaries from the four ratios; the existing prune-then-summarize tiered
  pipeline keys off the real context shape (ContextPromptTokens) with
  billable-token fallback. Config re-validation keeps the chain
  soft < snip < compact < force legal on every change.
• Config: reasonix config compact-ratio [--local] [VALUE] accepts
  10–95%; new snip-ratio command accepts 5–95%. Project-local values
  override the shared user config used by desktop and new CLI sessions.
• Control: SessionHistory.CompactThresholds() and
  ContextInfo's soft/snip/force ratios feed the desktop gauge; the
  settings view exposes the slider.
• Desktop: settings slider with soft/snip/compact/force pins, real
  occupancy ring (ContextReport + maintenance), context capacity pins in
  the overview, and per-threshold copy in zh/zh-TW.

Docs: docs/SPEC.md context-maintenance section rewritten for the tiered
thresholds (removed the "65–85%" single-threshold description).

Commit 2 is the ratchet/budget bookkeeping only (repolint baseline growth +
bundle budgets for the added code and locale copy), kept separate from the
feature diff for review.

Verification

• go build ./internal/... and go build ./... (desktop) pass
• go vet clean on internal/agent, internal/control, internal/config
• go test ./internal/agent/ ./internal/control/ ./internal/config/ pass
• pnpm exec tsc --noEmit clean
• node scripts/check-bundle-budget.mjs all PASS
• go run ./tools/repolint clean (1958 baselined findings)

Cache-impact: none - compact* changes are threshold getters/computation only; the provider-visible prefix stays byte-identical
Cache-guard: no prefix-assembly path changed; run go test ./internal/boot/ (prefix stability effect tests) plus the agent/control/config suites above
System-prompt-review: complyue (author) - internal/config threshold keys feed the config surface but do not alter the byte-stable system-prompt prefix
Documentation-impact: updated - docs/SPEC.md context-maintenance section rewritten for the four tiered thresholds

[complyue]

Here's updated UI:

Note it's now log-scale for the x-axis, so lower ranges occupy more horizontal space.

Settings:

Right Panel:

[SivanCola]

Thank you. I will start the review once you are ready.

[SivanCola]

Thanks for the thoughtful UI work and focused tests. I reviewed this branch against the latest main-v2, and there is an important architectural conflict to resolve before rebasing.

#8244 has now landed and intentionally replaced the former multi-threshold maintenance path with one cache-first compact_ratio trigger. On current main-v2:

• soft_compact_ratio, tool_result_snip_ratio, and compact_force_ratio are compatibility fields that are cleared during config loading;
• automatic snip/prune projections are no-ops;
• only compact_ratio (default 85%) drives automatic context maintenance.

This also exposes a semantic mismatch in the current four-thumb UI: in this branch, Snip is not an independent trigger at 60%. Tool-result cleanup starts only when Compact is reached (80% by default), and Snip is the target the cleanup result must fall below to avoid summary compaction. Presenting it as a separate cleanup trigger would therefore be misleading.

A mechanical rebase would either leave three slider thumbs disconnected from runtime behavior or require reverting #8244's cache-first contract, which could cause earlier prompt rewrites and lower prompt-cache reuse. #8265 has also removed the ContextPanel short-view block, so that block should not be reintroduced during conflict resolution.

The parts that still fit the current architecture are valuable:

• live capacity visualization aligned with the actual single Compact threshold;
• a single-threshold settings control;
• the over-threshold resume guard, after moving confirmation before the mutating ResumeSessionPageForTab / OpenChannelSessionPageForTab calls;
• immediate context and balance refresh after compaction_done.

Could you please re-scope this PR around the current single-threshold architecture and preserve #8265's ContextPanel deletion? If four independently configurable thresholds are still desired, that should be a separate product/architecture proposal because it changes the behavior and cache guarantees established by #8244.