lnrpc+lncli: add reverse ordering to GetTransactions

[Vandit1604]

Adds a reverse field to GetTransactionsRequest and a --reverse flag to lncli listchaintxns, so transactions can be listed oldest first. Fixes #7316.

Root cause

The wallet does not set the response order. RPCTransactionDetails (lnrpc/rpc_utils.go) re-sorts by confirmation count, so results are always newest first regardless of how start_height/end_height are ordered. #9558 also rejects start_height > end_height at the CLI, so the old swap-the-heights trick is gone. Reversing the slice in the wallet layer does nothing, because this sort runs after it, so the flag goes into the sort.

Behaviour

• reverse unset: unchanged, newest first.
• reverse set: oldest to newest, unconfirmed last.
• Field defaults to false, so existing clients are unaffected.

Pagination

index_offset/max_transactions are applied in the wallet layer before this sort, so --reverse sets display order, not which page you get. That split predates this change and is out of scope.

Testing

• TestRPCTransactionDetailsReverse covers both orderings and unconfirmed placement.
• On a simnet node: default returns 403,402,401, --reverse returns 401,402,403.

[github-actions]

🔴 PR Severity: CRITICAL

gh pr view | 9 files | 133 lines changed

🔴 Critical (1 file)

• rpcserver.go - core server coordination file; explicitly critical regardless of diff size

🟠 High (3 files)

• lnrpc/lightning.pb.go - generated RPC/API message definitions
• lnrpc/rpc_utils.go - RPC/API definitions; contains the transaction-detail sort/order logic being modified
• lnrpc/walletrpc/walletkit_server.go - RPC/API definitions

🟡 Medium (3 files)

• cmd/commands/commands.go - lncli CLI command (client-side, not server)
• lnrpc/lightning.proto - proto API definition change
• lnrpc/lightning.swagger.json - generated swagger from the proto change

🟢 Low (2 files)

• docs/release-notes/release-notes-0.22.0.md - release notes
• lnrpc/rpc_utils_test.go - test-only change

Analysis

This PR adds a reverse field to GetTransactionsRequest (proto + generated code) and a --reverse flag to lncli listchaintxns, changing ordering behavior in RPCTransactionDetails (lnrpc/rpc_utils.go). The overall diff is small (~9 files, ~133 lines) and well under the file/line thresholds that would otherwise trigger a severity bump.

However, the change touches rpcserver.go, which is explicitly called out as CRITICAL ("Core server coordination") in the classification rules regardless of the size of the edit there. That single touch point sets the PR's overall severity to CRITICAL. The remaining files are consistent with a routine, low-risk RPC/API surface addition (new opt-in field, default false, existing clients unaffected) plus its corresponding CLI flag and tests.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}