chore(deps): bump invoices from 2.0.6 to 6.0.5

[Matobi98]

Summary

• Bump invoices from 2.0.6 to 6.0.5.

Note: invoices@6.0.0+ requires Node.js >= 22. This PR depends on #915 (bump Node engine to 22) and will fail CI until that one is merged into main.

Why

invoices@6.0.0+ includes a correctness/security fix in bolt11/request_details.js: when a BOLT11 payment request had multiple id tagged fields, the parser kept overwriting sum.id with the last one found instead of the first. We rely on invoice.id (the payment request hash) as the source of truth for payment tracking:

• bot/validations.ts validates invoice.id exists before accepting an invoice
• ln/pay_request.ts stores it as order.payout_hash
• ln/resubscribe_invoices.ts and ln/subscribe_invoice.ts look up orders by hash: invoice.id

A malformed or adversarial invoice with a duplicated id tag could previously cause the bot to track the wrong payment hash. This fix makes that path correct.

Changes

• package.json: invoices 2.0.6 → 6.0.5
• package-lock.json updated accordingly

Breaking changes reviewed

Went through the full invoices CHANGELOG from 2.0.6 to 6.0.5. All breaking changes are Node.js engine bumps (16 → 18 → 20 → 22), already covered by #915. No other breaking change applies to this codebase — we only use parsePaymentRequest in production code (createUnsignedRequest/createSignedRequest are only used in tests), and none of the affected fields (CLTV delta default, P2TR fallback addresses, signet support) are used here.

Testing

• npm install — installs cleanly
• npx tsc --noEmit — no type errors
• npm run lint — no lint errors
• npm test — 233 passing, 4 pre-existing failures unrelated to this change (missing getCommunityByIdentifier, from unrelated in-progress work)
• Manually tested the /sell and /buy flows end-to-end

[coderabbitai]

Warning

Review limit reached

@Matobi98, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 33 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 63052cdc-f1b1-4c04-98e8-71d880acaf74

📥 Commits

Reviewing files that changed from the base of the PR and between 1ff500b and 6f3f672.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (1)

• package.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ermeme]

I found one blocking sequencing/runtime issue.

invoices@6.0.5 declares engines.node >=22, but this PR's current head still advertises/supports Node 20 in the checked tree (package.json keeps engines.node >=20.0.0 and the Dockerfile still builds/runs on node:20-alpine). The PR body says this depends on #915, but as-is this head can still be merged or tested without the Node 22 runtime changes, which would leave production on an unsupported Node version for the new direct dependency.

Please either include the Node 22 runtime/CI changes here, or rebase/retarget this PR on top of #915 after that PR updates every runtime/CI path to Node 22. Once the effective merge result has Node 22 everywhere, the dependency bump itself looks fine.

Verification performed on the current head:

• GitHub checks for 6f3f67243d0861748b5887d000c1c0a76fc23213: CodeQL, Analyze, Lint, and ci_to_main are green.
• Local Node: v22.22.2 / npm 10.9.7.
• npm ci --ignore-scripts, npx tsc --noEmit, and npm run lint passed.
• Confirmed invoices@6.0.5 still exports parsePaymentRequest, createUnsignedRequest, and createSignedRequest; its package metadata requires Node >=22.
• Full local tests were blocked by missing system canvas build deps on this runner, so I relied on the GitHub CI result for full install/test coverage.

[grunch]

closing in favor of #917