Integrate the real grydlock-oracle-adapter behind a feature flag

[knytcomics-ui]

Summary

src/adapter/oracleAdapter.ts is an explicit stub (getScore returns a deterministic hash-based number, :6-17) -- per README's roadmap and its own doc comment, this is the single blocking item before real interception has any value ('Do not build real interception until the adapter returns a real score' -- README.md:181).

Current Behavior / Relevant Code

• src/adapter/oracleAdapter.ts:1-17.
• README.md roadmap section, lines 176-181.
• src/popup/App.tsx:2 and src/background/background.ts:2 are the two call sites depending only on getScore's signature.

Why This Matters

This is the highest-leverage single issue in the whole project -- everything else (tiers, popup, interception) is already built and tested against the stub's contract; wiring the real scoring source is what turns Gryd Lock from a demo into a functioning product.

Proposed Solution

• Introduce an environment-driven switch (e.g. import.meta.env.VITE_ORACLE_MODE) selecting between the stub and a real grydlock-oracle-adapter import, keeping the stub available for offline dev/testing per the existing DevScoreSlider workflow.
• Preserve getScore(destination: string): Promise's exact signature so no downstream code changes.
• Add integration tests against the real adapter's contract (mocked network layer) alongside the existing stub tests.

Acceptance Criteria

• Production builds call the real adapter; dev builds retain the stub/dev-slider workflow.
• oracleAdapter.test.ts covers both code paths.
• README roadmap checkbox for 'Swap the stub score for a live one' updated.

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: L (large, ~1-2 weeks)
Difficulty: Advanced — this issue assumes familiarity with the codebase's MV3 service-worker architecture, the Freighter interception protocol, and/or the Stellar SDK.

[Heazzy500]

Hi, I'm Heazzy 500. My plan is to implement the requested functionality using the project's existing patterns, ensure backward compatibility, cover important edge cases, and provide solid test coverage.

[Primex-hub]

I would love to solve this issue