metrics(issue-quality): define the issue-quality score — signals, weighting, documented method

[JSONbored]

Problem

Before anything can be measured or optimised, "was this issue well-formed?" needs a
concrete definition grounded in signals we actually persist.

Scope

Define and document a per-issue quality score from these candidate signals:

• first-pass acceptance — the issue's PR reached action: merge on its first
  head sha (single decision_records row)
• revision depth — count of decision_records rows for the PR before acceptance
• disposition mix — merge / close / hold rates and their reason_code distribution
• time-to-first-PR — issue creation to first linked PR, as a legibility proxy
• abandonment — a PR opened against the issue then closed without merge
• post-merge reversion — from the existing github-truth outcome scan
• contention — multiple contributors attempting the same issue (ambiguity signal)

Deliverables: a written definition with the weighting and its rationale; the exact
decision_records / pull_request_reviews / check_summaries fields each signal reads;
explicit statement of what the score does NOT capture (e.g. issue value, only issue
executability); and the handling of issues with zero linked PRs.

Acceptance

A documented definition precise enough that two people computing it independently from
the same data get the same number.

Out of scope

Computation and backfill (sibling), and any use of the score to gate or rank work.

[linear-code]

JSO-7075