Maintainer risk x value triage view

[JSONbored]

Context

Part of #4737 (parent epic — unlocks phase). Depends on the panel-surfacing
sub-issue (sibling sub-issue in this epic) and the existing src/signals/slop.ts risk score.

Why this is worth building

Slop-risk (existing) answers "is this bad?" The new improvement signal (this epic) answers "is this
good?" Neither alone can distinguish safe-but-worthless churn (a trivial rename, a reformat) from
risky-but-valuable work (a real fix in a gnarly function) from actual slop. Crossed together they produce
a genuine 2×2 a maintainer can triage against:

	low value	high value
low risk	technically fine, but is it worth attention? (scope-padding / busywork flag)	fast-track candidate
high risk	weakest quadrant — closest to reject	deserves careful human review, don't auto-reject on risk alone

This is the direct positive-axis complement to this product's stated wedge (a shared definition of "real
contribution vs. AI slop") — slop-risk alone only ever produces half of that definition.

Deliverables

• A combined read of SlopAssessment (existing) and the new deterministic + LLM improvement signal
  (sibling sub-issues), computed per-PR.
• A surface for it — start with the existing PR panel (a compact quadrant label, e.g. "risk: low ·
  value: moderate") rather than a new dashboard page; a dedicated maintainer-dashboard visualization
  (apps/gittensory-ui/) can follow later if the panel version proves useful, but is not required for
  this issue's acceptance.
• Optional: a queue-level view (which open PRs across a repo/install fall in the "high risk / low value"
  quadrant, as a maintainer triage worklist) — implementer's call whether to fold into this issue or spin
  out as a fast-follow; note the decision in the PR description either way.

Requirements

• Advisory/display-only — does not change any gate/disposition logic (epic design constraint 2).
• Both inputs must already be resolvable for the repo (slop-risk always is; the improvement signal only
  when improvementSignal is enabled) — degrade to slop-risk-only display when the new signal isn't
  active for that repo, don't block on it.
• Language for the quadrant labels goes through the same sanitizer-safety discipline as the rest of this
  epic (no "score"/forbidden vocabulary in any dynamically generated text).

Acceptance criteria

• A PR's risk × value quadrant is computed and rendered somewhere a maintainer actually sees it
  (panel section at minimum).
• Repos without the improvement signal enabled see unchanged (slop-risk-only) behavior — no
  regression to today's panel for anyone who hasn't opted in.
• Tests cover all four quadrant combinations plus the "improvement signal unavailable" degraded case.
• UI evidence (screenshot) of the rendered quadrant in a real PR comment.

[linear-code]

JSO-3428