Check XBull extension version before attempting connection

[Kingsman-99]

Description

XBullAdapter connects to the XBull browser extension without verifying the extension version. Older extension versions do not support the current API surface, causing cryptic runtime errors.

Acceptance Criteria

• Before connecting, the adapter reads window.xBullSDK.version or equivalent
• Versions below MIN_XBULL_VERSION (export this constant) reject with an ExtensionVersionError listing the required version
• Compatible versions proceed with the existing connection flow
• Unit tests pass

Context

• Target file: src/wallets/adapters/XBullAdapter.ts
• Set MIN_XBULL_VERSION to the first version that supports the current API

[woahwhattheheck]

Submitted a PR for this: #838

The check runs before window.xbull.connect() is called, so an unsupported
extension is rejected up front rather than failing later.

Three points worth your eye:

Where the version is read. The issue names window.xBullSDK.version,
while this file declares window.xbull. Builds differ in which handle carries
it, so the adapter reads window.xbull.version and falls back to
window.xBullSDK.version. Both paths are tested.

getAddress() is gated too, since it also calls connect() when there is
no cached key — but it does not re-check once a key is cached, so an extension
update mid-session cannot turn a working adapter into a spurious failure.

It fails closed, including when no version is reported. A build too old to
expose a version is almost certainly too old for the API surface used here,
and connecting anyway produces exactly the cryptic failure the check exists to
replace. The error says "version not reported" rather than inventing a value,
and skipVersionCheck covers a build that is known-good but silent. Glad to
make absence permissive instead if you would rather only an explicit low
version fail.

MIN_XBULL_VERSION is set to 1.4.0 as the first version exposing the
object-shaped connect()/sign() surface this adapter uses — easy to move if
you would draw the line elsewhere.

new XBullAdapter() still works unchanged; the constructor takes an optional
options object.

27/27 tests pass, offline. tsc --noEmit shows the same 210 errors as
unmodified main, none in this file.

[woahwhattheheck]

I'd like to work on this — requesting assignment.

I should be straight about the order of events: I opened PR #838 for this
issue before asking. CONTRIBUTING is explicit that coding should not start
until a maintainer assigns the issue, and I did not read it before starting.
That is my mistake, not a grey area.

The PR stands on its own if it is useful to you, but I am not claiming any
standing from it. If you would rather assign this to someone else, say so and
I will close it — no need to explain.

If you do assign me, I will re-push under your branch convention as
feat/issue-771-xbull-version-gate; my current branch omits the issue- prefix.