feat: Add decodeLightningInvoice to Keymaster

[macterra]

Summary

• Add decodeLightningInvoice() method to Keymaster class using light-bolt11-decoder for local BOLT11 decoding
• Add POST /api/v1/lightning/decode API endpoint; KeymasterClient calls the API like all other methods
• Add lightning-decode CLI command
• Add 6 unit tests using BOLT11 spec test vectors (coffee invoice, donation invoice)
• Add 14 client API tests covering all 7 lightning endpoints (success + error for each)
• Fix pre-existing no-throw-literal lint issue in drawbridge-client.ts
• Sync Python SDK with JS client: add 26 missing methods (lightning, nostr, assets, polls, wallet, DID update)

Closes #145

Python SDK methods added

Group	Methods
Lightning	add_lightning, remove_lightning, get_lightning_balance, create_lightning_invoice, pay_lightning_invoice, check_lightning_payment, decode_lightning_invoice
Nostr	add_nostr, remove_nostr, export_nsec, sign_nostr_event
Assets	create_asset, list_assets, clone_asset, merge_data, transfer_asset
Polls	send_poll, send_ballot, view_ballot, add_poll_voter, remove_poll_voter, list_poll_voters
Wallet	change_passphrase, export_encrypted_wallet
DID	update_did

Test plan

• All 29 lightning unit tests pass (tests/keymaster/lightning.test.ts)
• All 238 client tests pass (tests/keymaster/client.test.ts)
• keymaster lightning-decode <bolt11> decodes invoices correctly (verified on live invoice)
• Lint clean
• OpenAPI spec regenerated with correct paths

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

packages/gatekeeper/src/drawbridge-client.ts:20

• throwError now throws a generic Error for 404s (and a raw string for non-HTTP errors). This changes the error shape compared to the previous { type, error } object and to the rest of the codebase where callers often rely on structured Archon errors with a .type (e.g. LightningUnavailableError.type). Consider throwing new LightningUnavailableError('Server does not support Lightning') (from @didcid/common/errors) for the 404 case, and throwing error (or new Error(...)) instead of error.message for the non-response case to keep errors consistently Error-like/typed.

function throwError(error: any): never {
    if (error.response) {
        if (error.response.status === 404) {
            throw new Error('Lightning service unavailable: Server does not support Lightning');
        }
        throw error.response.data;
    }
    throw error.message;
}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.