feat(extensions): add extension loader infrastructure (#3)

## Summary

- Adds a modular extension system for Lightning.Pub enabling third-party plugins
- Provides isolated SQLite databases per extension for data safety
- Implements ExtensionContext API for accessing Lightning.Pub services (payments, Nostr, storage)
- Supports RPC method registration with automatic namespacing
- Includes HTTP route handling for protocols like LNURL
- Event routing for payment receipts and Nostr events
- Comprehensive documentation with architecture overview and working examples

## Key Components

- `src/extensions/types.ts` - Core extension interfaces
- `src/extensions/loader.ts` - Extension discovery, loading, and lifecycle management
- `src/extensions/context.ts` - Bridge between extensions and Lightning.Pub services
- `src/extensions/database.ts` - SQLite isolation with WAL mode
- `src/extensions/README.md` - Full documentation with examples

## ExtensionContext API

| Method | Description |
|--------|-------------|
| `getApplication()` | Get application info |
| `createInvoice()` | Create Lightning invoice |
| `payInvoice()` | Pay Lightning invoice |
| `getLnurlPayInfo()` | Get LNURL-pay info for a user (enables Lightning Address/zaps) |
| `sendEncryptedDM()` | Send Nostr DM (NIP-44) |
| `publishNostrEvent()` | Publish Nostr event |
| `registerMethod()` | Register RPC method |
| `onPaymentReceived()` | Subscribe to payment callbacks |
| `onNostrEvent()` | Subscribe to Nostr events |

## Test plan

- [x] Review extension loader code for correctness
- [x] Verify TypeScript compilation succeeds
- [x] Test extension discovery from `src/extensions/` directory
- [x] Test RPC method registration and routing
- [x] Test database isolation between extensions

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: boufni95 <boufni95@gmail.com>
Co-authored-by: Patrick Mulligan <patjmulligan@protonmail.com>
Reviewed-on: #3

proto/others/invoices.proto

@@ -1,11 +1,29 @@
 syntax = "proto3";
 
-import "lightning.proto";
-
 package invoicesrpc;
 
+import "lightning.proto";
+
 option go_package = "github.com/lightningnetwork/lnd/lnrpc/invoicesrpc";
 
+/*
+ * Comments in this file will be directly parsed into the API
+ * Documentation as descriptions of the associated method, message, or field.
+ * These descriptions should go right above the definition of the object, and
+ * can be in either block or // comment format.
+ *
+ * An RPC method can be matched to an lncli command by placing a line in the
+ * beginning of the description in exactly the following format:
+ * lncli: `methodname`
+ *
+ * Failure to specify the exact name of the command will cause documentation
+ * generation to fail.
+ *
+ * More information on how exactly the gRPC documentation is generated from
+ * this proto file can be found here:
+ * https://github.com/lightninglabs/lightning-api
+ */
+
 // Invoices is a service that can be used to create, accept, settle and cancel
 // invoices.
 service Invoices {
@@ -17,30 +35,39 @@ service Invoices {
     rpc SubscribeSingleInvoice (SubscribeSingleInvoiceRequest)
         returns (stream lnrpc.Invoice);
 
-    /*
+    /* lncli: `cancelinvoice`
     CancelInvoice cancels a currently open invoice. If the invoice is already
     canceled, this call will succeed. If the invoice is already settled, it will
     fail.
     */
     rpc CancelInvoice (CancelInvoiceMsg) returns (CancelInvoiceResp);
 
-    /*
+    /* lncli: `addholdinvoice`
     AddHoldInvoice creates a hold invoice. It ties the invoice to the hash
     supplied in the request.
     */
     rpc AddHoldInvoice (AddHoldInvoiceRequest) returns (AddHoldInvoiceResp);
 
-    /*
+    /* lncli: `settleinvoice`
     SettleInvoice settles an accepted invoice. If the invoice is already
     settled, this call will succeed.
     */
     rpc SettleInvoice (SettleInvoiceMsg) returns (SettleInvoiceResp);
 
     /*
-    LookupInvoiceV2 attempts to look up at invoice. An invoice can be refrenced
+    LookupInvoiceV2 attempts to look up at invoice. An invoice can be referenced
     using either its payment hash, payment address, or set ID.
     */
     rpc LookupInvoiceV2 (LookupInvoiceMsg) returns (lnrpc.Invoice);
+
+    /*
+    HtlcModifier is a bidirectional streaming RPC that allows a client to
+    intercept and modify the HTLCs that attempt to settle the given invoice. The
+    server will send HTLCs of invoices to the client and the client can modify
+    some aspects of the HTLC in order to pass the invoice acceptance tests.
+    */
+    rpc HtlcModifier (stream HtlcModifyResponse)
+        returns (stream HtlcModifyRequest);
 }
 
 message CancelInvoiceMsg {
@@ -84,7 +111,7 @@ message AddHoldInvoiceRequest {
     */
     bytes description_hash = 4;
 
-    // Payment request expiry time in seconds. Default is 3600 (1 hour).
+    // Payment request expiry time in seconds. Default is 86400 (24 hours).
     int64 expiry = 5;
 
     // Fallback on-chain address.
@@ -120,8 +147,9 @@ message AddHoldInvoiceResp {
     uint64 add_index = 2;
 
     /*
-    The payment address of the generated invoice. This value should be used
-    in all payments for this invoice as we require it for end to end
+    The payment address of the generated invoice. This is also called
+    the payment secret in specifications (e.g. BOLT 11). This value should
+    be used in all payments for this invoice as we require it for end to end
     security.
     */
     bytes payment_addr = 3;
@@ -172,4 +200,52 @@ message LookupInvoiceMsg {
     }
 
     LookupModifier lookup_modifier = 4;
+}
+
+// CircuitKey is a unique identifier for an HTLC.
+message CircuitKey {
+    // The id of the channel that the is part of this circuit.
+    uint64 chan_id = 1;
+
+    // The index of the incoming htlc in the incoming channel.
+    uint64 htlc_id = 2;
+}
+
+message HtlcModifyRequest {
+    // The invoice the intercepted HTLC is attempting to settle. The HTLCs in
+    // the invoice are only HTLCs that have already been accepted or settled,
+    // not including the current intercepted HTLC.
+    lnrpc.Invoice invoice = 1;
+
+    // The unique identifier of the HTLC of this intercepted HTLC.
+    CircuitKey exit_htlc_circuit_key = 2;
+
+    // The amount in milli-satoshi that the exit HTLC is attempting to pay.
+    uint64 exit_htlc_amt = 3;
+
+    // The absolute expiry height of the exit HTLC.
+    uint32 exit_htlc_expiry = 4;
+
+    // The current block height.
+    uint32 current_height = 5;
+
+    // The wire message custom records of the exit HTLC.
+    map<uint64, bytes> exit_htlc_wire_custom_records = 6;
+}
+
+message HtlcModifyResponse {
+    // The circuit key of the HTLC that the client wants to modify.
+    CircuitKey circuit_key = 1;
+
+    // The modified amount in milli-satoshi that the exit HTLC is paying. This
+    // value can be different from the actual on-chain HTLC amount, in case the
+    // HTLC carries other valuable items, as can be the case with custom channel
+    // types.
+    optional uint64 amt_paid = 2;
+
+    // This flag indicates whether the HTLCs associated with the invoices should
+    // be cancelled. The interceptor client may set this field if some
+    // unexpected behavior is encountered. Setting this will ignore the amt_paid
+    // field.
+    bool cancel_set = 3;
 }