Implement xBull wallet interception adapter

[knytcomics-ui]

Summary

Implement an xBull-specific WalletAdapter (depends on the WalletAdapter abstraction issue in this batch) mirroring the Freighter interception pattern -- research xBull's actual injected API/postMessage protocol, hook its signing flow, and route through the existing resolveOutcome/scoring/popup pipeline unchanged.

Current Behavior / Relevant Code

• README.md:49 lists xBull as a next target after Freighter; no xBull-specific code exists anywhere in the repo today.

Why This Matters

Second-wallet support is the proof that the WalletAdapter architecture actually generalizes, and directly expands the product's addressable user base per the stated roadmap.

Proposed Solution

• Research and document xBull's signing-request interception point (likely a different postMessage shape or injected window object than Freighter's).
• Implement the adapter, reusing resolveOutcome, decodeTransaction, and the popup entirely as-is.
• Add manual test notes (real xBull install) and any automatable protocol-shape tests.

Acceptance Criteria

• xBull signing requests are intercepted, scored, and warned on using the existing pipeline.
• No changes required to background.ts, decodeTransaction.ts, or the popup beyond what the WalletAdapter abstraction already generalized.

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: Multi-Wallet Generalization
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.

[grantfox-oss]

🦊 GrantFox — @mordabdul1 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #29)
2. Your PR will be reviewed by the Gryd-lock maintainers

Good luck! Track your progress on GrantFox.