fix: correct scantxoutset version range

[JasonZhouPW]

Summary

• Corrects the scantxoutset method version range from =>0.17.0 to >=0.17.0.
• Adds a focused requester regression test proving scantxoutset is allowed for version: '0.17.0'.

Validation

• npm ci --ignore-scripts
• ./node_modules/.bin/mocha --timeout 20000 --require should test/requester_test.js
• ./node_modules/.bin/eslint src/methods.js test/requester_test.js
• git diff --check

Notes

• Dependency installation was run with npm scripts disabled to avoid the existing Docker Compose lifecycle script in package.json.
• The targeted test avoids requiring a live BGLd node by stubbing postAsync.

Bounty context: Bitgesell improvement / PR bounty program, related to BitgesellOfficial/bitgesell#81 and BitgesellOfficial/bitgesell#39. Payout details can be provided after maintainer approval.

[MyTH-zyxeon]

Review-assist note for the Bitgesell #81 improvement lane.

I checked the public diff for this PR. It looks like a small, concrete RPC compatibility fix rather than a broad cleanup:

• scantxoutset.version changes from =>0.17.0 to >=0.17.0; the old operator appears to make the version gate invalid or too restrictive for the intended Bitcoin Core 0.17+ method.
• The new regression test exercises version: '0.17.0' and stubs postAsync, so it verifies requester/method gating without requiring a live BGLd node.
• Scope is limited to src/methods.js plus one requester test; no wallet signing path, RPC credentials, Docker lifecycle, or live-node behavior is introduced by the patch.

Suggested maintainer checks before merge:

• run the targeted requester test and eslint command from the PR body
• confirm the version-gating parser treats >=0.17.0 consistently with other methods in this package
• optionally add/verify one negative boundary (0.16.x) if maintainers want explicit lower-bound protection

From the public patch shape, this looks like a low-risk, reviewable fix for the bounty/improvement queue.