Surface score explanation and reason codes from the oracle in the warning popup

[knytcomics-ui]

Summary

TierWarning.tsx shows only a numeric score and a static per-tier message (src/lib/tiers.ts:10-47) -- there's no 'why' (e.g. destination created 2 minutes ago, linked to N reported scam addresses). Once real scoring lands, the underlying oracle will very likely carry reason data that's currently unused.

Current Behavior / Relevant Code

• src/lib/tiers.ts:3-8 (TierInfo has no field for dynamic reasons).
• src/popup/TierWarning.tsx:1-38.
• src/adapter/oracleAdapter.ts:6 (getScore returns a bare number, no structured explanation).

Why This Matters

A numeric score with no explanation is far less actionable and far less trust-building for a user deciding whether to cancel a real financial transaction than a score paired with concrete reasons.

Proposed Solution

• Extend getScore's contract to something like getScoreDetails(destination): Promise<{ score: number; reasons?: string[] }>, threading the richer shape through resolveOutcome, the runtime messages, and into TierWarning.
• Render reasons as a list under the tier message, gracefully hiding the section when no reasons are available (e.g. still on the stub).
• Update all touched tests (tiers.test.ts, resolveOutcome.test.ts, App.test.tsx).

Acceptance Criteria

• Reason data flows end-to-end from adapter to popup when present.
• UI degrades cleanly (no empty bullet list) when reasons are absent.

Definition of Done

• npm run lint, npm run typecheck, npm test, and npm run build all pass locally and in CI
• New or changed behavior is covered by unit tests (and integration/E2E tests where the change touches interception, background messaging, or the popup)
• Any user-facing or architectural change is reflected in README.md
• No regressions to the existing test suite or existing tier/interception behavior

How to Claim This Issue (Application Process)

1. Comment first. Post a short implementation plan on this issue — your proposed approach, the files you expect to touch, and any open questions — before writing code. This prevents duplicate effort and lets a maintainer flag concerns early, which matters especially for an issue at this complexity level.
2. Wait for assignment. A maintainer will review your plan and assign the issue to you, typically within 48 hours. Please do not open a draft PR before you're assigned.
3. Stay active. If there's no visible activity (commits or comments) for 10 days after assignment, the issue may be unassigned and reopened to other contributors.
4. Submit a scoped PR. Reference this issue (Closes #<issue-number>), keep the diff scoped to the acceptance criteria above, and ensure all CI gates pass before requesting review.
5. Engage with review. Respond to review feedback within a reasonable timeframe; PRs with no response after 7 days may be closed pending resubmission when you're ready to pick it back up.

---

Category: Oracle Adapter & Scoring
Estimated effort: M (medium, ~3-5 days)
Difficulty: Advanced — this issue assumes familiarity with the codebase's MV3 service-worker architecture, the Freighter interception protocol, and/or the Stellar SDK.

[Primex-hub]

I would love to solve this issue