fix(decision-pack): clamp lane shares to match preview math

[philluiz2323]

Closes #452.

buildRepoDecision computed rewardUpside lane shares from raw, unclamped registry config, even though its comment claims parity with preview.ts laneMath — which clamps both shares to [0, 1]. Registry config is untrusted and unclamped at ingestion (registry/normalize.ts only checks Number.isFinite), so an out-of-range issueDiscoveryShare > 1 produced a negative directPrShare (and an inflated issue-discovery share / repo priority), contradicting the scoring preview and surfacing a nonsensical negative value in contributor-facing copy (whyThisHelpsFor).

Changes

• Clamp both emissionShare and issueDiscoveryShare to [0, 1] before the slice math, exactly as preview.ts does (clamp already defined in-file).
• Add a fixture with issueDiscoveryShare = 1.5 (and -0.5) asserting directPrShare >= 0 and parity with the clamped preview slices.

Verification

• npx vitest run test/unit/decision-pack.test.ts → 44/44 pass. The new fixture fails against the old code (old directPrShare = -0.0045).

Note: distinct from #391/#392, which fixed the OSS_EMISSION_SHARE factor on these same lines; this is the remaining clamp gap.

[ghost]

Note

Gittensory Gate skipped

PR closed before full evaluation. No late first comment was created.

Signal	Result	Evidence	Action
Gate result	⚠️ Skipped	#453 is no longer open.	No action.

---

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

[JSONbored]

Reviewed the patch and current CI state. The decision-pack lane-share math now clamps registry shares the same way preview math does, and the regression covers both >1 and negative issue-discovery shares. CI is green. No merge action taken.