LND

sqldb/sqlc: add non-terminal payment query

FetchInFlightPayments needs a dedicated SQL query that can return
non-terminal payments without relying on the unresolved-attempt scan.
The first version of that query fixed correctness, but the follow-up
selector measurements showed a UNION-based shape was materially
faster while returning the same payment set.

Use the inflight regression tests as evidence. The tests still fail on
SQL before the Go payment store is wired up, but this commit adds the
final SQL surface the later wiring commit depends on.

Add FetchNonTerminalPayments to the SQL query set, regenerate the sqlc
bindings, add the PaymentAndIntent adapters for the new row type, and
use the UNION-based candidate selection so the final query shape lands
in one commit.

paymentsdb: add AMP hash regression test

SQL writes store the payment identifier in payment_hash for each
attempt. That is wrong for AMP payments, because the payment
identifier is the SetID while each shard carries its own HTLC hash.

Add TestRegisterAttemptPreservesAttemptHash as evidence. It passes on
KV and fails on SQL before the fix because SQL reads the attempt hash
back as the payment identifier.

paymentsdb: preserve AMP attempt hashes in sql store

Live SQL writes stored the payment identifier in payment_hash for
each attempt. That works for legacy payments, but it breaks AMP
because the payment identifier is the SetID while each shard carries
its own HTLC hash.

Use TestRegisterAttemptPreservesAttemptHash as evidence. The test now
passes on both KV and SQL.

Fix this by persisting attempt.Hash when it is present and only
falling back to the payment identifier when the attempt hash is nil.
That restores KV parity for AMP attempt reloads.

paymentsdb: add inflight recovery regression tests

SQL FetchInFlightPayments only returns payments with an unresolved
attempt row. KV returns every non-terminal payment, including
retryable payments with only failed attempts and payments that have
been initialized but have not registered any HTLCs yet.

Add TestFetchInFlightPaymentsIncludesRetryablePayments and
TestFetchInFlightPaymentsIncludesInitiatedPayments as evidence. Both
tests pass on KV and fail on SQL before the fix.

chainreg: accommodate buried taproot deployment in Bitcoin Core v31

Removes "taproot" from deployments:
https://github.com/bitcoin/bitcoin/pull/26201

Adds "script_flags" field to RPC getdeploymentinfo:
https://github.com/bitcoin/bitcoin/pull/32998

docs: add release note for cursor-based invoice pagination

invoices+sqldb/sqlc: replace offset-based pagination with cursor-based

The invoice filter queries (FetchPendingInvoices,
FilterInvoicesBySettleIndex, FilterInvoicesByAddIndex,
FilterInvoicesForward, FilterInvoicesReverse) all used LIMIT+OFFSET for
internal pagination. This causes SQLite to build an ephemeral temp
B-tree for every page to implement the OFFSET skip, making each
successive page O(offset+limit). On nodes with large invoice histories
this compounds into a significant CPU cost — profiling showed
FilterInvoicesReverse consuming 53% of total CPU, with _sqlite3BtreeInsert
and _balance_nonroot (2.4s combined) appearing inside the SELECT due to
the temp B-tree being built and rebalanced to skip rows.

Replace the OFFSET loop (queryWithLimit) with cursor-based pagination
across all four callers in sql_store.go:

- FetchPendingInvoices: add id_cursor param, advance cursor to
last_id + 1 each page.
- InvoicesSettledSince: add id_cursor param alongside the existing
settle_index lower bound, advance cursor to last_id + 1 each page.
- InvoicesAddedSince: cursor starts at idx+1, advances to last_id+1.
- QueryInvoices: forward cursor starts at IndexOffset+1 and advances
by +1; reverse cursor starts at IndexOffset-1 (or MaxInt64) and
advances by -1. Inclusive SQL bounds (>= / <=) are preserved so
query semantics and all existing callers are unchanged.

The queryWithLimit helper is removed as it has no remaining callers.

Each page now performs a single PK seek + forward scan of exactly
page_size rows with no temp sort structure, matching the cursor-based
pattern already used by the payments filter queries.

sqldb/v2: limit MigrationExecutor interface

This commit limits the MigrationExecutor interface due to the following
reasoning:

1. SkipMigrations() and DefaultTarget() should not be on the interface
Both are only used by ApplyAllMigrations, which immediately passes the
results back into the same executor. They are internal implementation
details and should be folded into ExecuteMigrations itself.

2. SetSchemaVersion and GetSchemaVersion are test-only but on the
production interface Every caller of these in sqldb/v2 is in test files.
The SetSchemaVersion comment even says "USE WITH CAUTION" — dangerous
test utilities should not be on an interface that every real consumer
must implement. They should be accessible on the concrete types only and
used directly in tests without going through the interface.

3. ExecuteMigrations should not take a MigrationTarget parameter for the
normal path On the normal startup path, callers just do
executor.ExecuteMigrations(executor.DefaultTarget(), stream) — asking
the executor for its default and handing it straight back. The method
should run to latest by default; a version override for tests can live
on the concrete type instead.

sqldb/v2: rename `ErrRetriesExceeded` error

rename the `ErrRetriesExceeded` error to `ErrTxRetriesExceeded`.

sqldb/v2: ensure SqliteConfig.MaxConnections is used

sqldb/v2: use `defaultMaxIdleConns` in SqliteStore

The code previously used `defaultMaxOpenConns` for both the maximum
number of open connections and the maximum number of idle connections in
the `SqliteStore`.

This commit updates the code to use `defaultMaxIdleConns` for the
maximum number of idle connections.

sqldb/v2: rename the `postgresErrMsgs` list

Rename the `postgresErrMsgs` list to `postgresRetriableErrMsgs`, in
order to clarify its usage.

sqldb/v2: add MaxIdleConnections & ConnMaxLifetime sqlite opts

sqldb/v2: rename MigrationConfig to MigrationDescriptor

sqldb/v2: clarify config options docs

The documentation for the `SqliteConfig.MaxConnections`,
`PostgresConfig.MaxOpenConnections` and
`PostgresConfig.MaxIdleConnections` previously stated that an unlimited
number was used when the value was set to 0. This is not the case
however, as setting the value to 0 will result in the default values
being used.

sqldb/v2: set predictable NewTestPgFixture container name

sqldb/v2: sync features with tapd's sqldb package

In order to make it possible to replace `tapd`'s internal `sqldb`
package with the new generic `sqldb/v2` package, we need to make sure
that all features and functionality that currently exist in the `tapd`
package are also present in the new `sqldb/v2` package.

This commit adds such additional missing features to the `sqldb/v2`
package.

sqldb/v2: move Sqlite test helpers to separate file

sqldb/v2: rename test db helper files

Previously, the test db helper files were suffixed with "_test", which
would indicate that the files specifically contained tests.
However, these files actually contain helper functions to be used
in tests, and are not tests themselves. To better reflect their
purpose, the files have been renamed to instead be prefixed with
"test_".

sqldb/v2: introduce sqldb/v2 `BaseDB`

This commit updates the definition of the `BaseDB` struct to decouple
it from lnd`s `sqlc` package. We also introduce new fields to the struct
to make it possible to track the database type used at runtime.

sqldb/v2: clarify no_sqlite `SqliteStore` intent

The docs of the `SqliteStore` for no sqlite build environments
previously didn't clarify that the actual `SqliteStore` implementation
under such build tag environments, didn't actually implement a real
sqlite store. This commit clarifies that in the docs.

sqldb/v2: introduce `MigrationStream`

This commit introduces a new struct named `MigrationStream`, which
defines a structure for migrations SQL migrations.

The `MigrationStream` struct contains the SQL migrations which will be
applied, as well as corresponding post-migration code migrations which
will be executed afterwards. The struct also contains fields which
define how the execution of the migrations are tracked.

Importantly, it is also possible to define multiple different
`MigrationStream`s which are executed, to for example define one `prod`
and one `dev` migration stream.

sqldb/v2: move all non lnd-specific v1 code to v2

This commit moves all non lnd-specific code of sqldb/v1 to the new
sqldb/v2 module.

Note however, that without additional changes, this package still needs
to reference lnd, as references to the lnd `sqlc` package is required
without further changes. Those changes will be introduced in the
upcoming commits, to fully decouple the new sqldb/v2 module from lnd.

sqldb/v2: Use `MigrationStream` for migrations

This commit updates the `sqldb/v2` package to utilize the new
`MigrationStream` type for executing migrations, instead of passing
`[]MigrationConfig`'s directly.

sqldb/v2: add base for sqldb/v2 module

In the upcoming commits, we will introduce a new sqldb module, sqldb
version 2.

The intention of the new sqldb module, is to make it generalizable so
that it contains no `lnd` specific code, to ensure that it can be reused
in other projects.

This commit adds the base of the new module, but does not include any
implementation yet, as that will be done in the upcoming commits.