multi: add --forget_node and --forget_address to lncli disconnect

[ZZiigguurraatt]

Extends lncli disconnect with two ways to prune a peer's stored
LinkNode state:

• --forget_node for whole-peer removal.
• --forget_address for surgical, per-address removal.

Both operations are gated by a shared --force flag when the requested
action would lose meaningful state:

• --forget_node drops the live connection (base disconnect behavior)
  and additionally deletes the peer's LinkNode entry. The LinkNode
  delete is refused if open channels still exist with the peer unless
  --force is also set.
• --forget_address <host:port> removes a single stored address from
  the peer's LinkNode entry. The live connection is left in place
  unless the removed address happens to be the currently-connected
  one, in which case the connection is dropped so lnd can re-dial via
  the remaining stored/gossip addresses. If the removed address would
  be the last one stored for the peer, behaviour depends on whether
  open channels exist: with no open channels the LinkNode entry is
  deleted automatically; with open channels the request is refused
  unless --force is also set. Note that after --forget_address --force removes the last stored address for a channel peer, the
  peer stays in the persistent-reconnect set — the peer-termination
  watcher falls back to the peer's NodeAnnouncement addresses for
  reconnect. --forget_node is the way to also stop reconnecting
  from our side (until lnd next restarts). Even with --forget_address --force, a channel peer is only truly orphaned when it also has
  no NodeAnnouncement.
• --force on its own is rejected. --forget_node and --forget_address
  are mutually exclusive.

Response Status carries a warning when --forget_address triggers the
last-address LinkNode delete.

DB helper:

• new channeldb.LinkNodeDB.RemoveAddressForPeer(pub, addr, allowLast)
  returning (deletedEntry bool, err error).
• new sentinel errors: ErrNodeAddressNotFound (address not stored
  for peer), ErrLastPeerAddress (refusing to remove last address
  without allowLast).

Server:

• DisconnectPeer signature grows forgetNode and force parameters.
• new ForgetPeerAddress method handles the per-address case,
  including the "disconnect if removed address is current" behaviour.
• all internal callers of DisconnectPeer updated to pass
  false, false.

Proto: DisconnectPeerRequest gains forget_node (2), force (3), and
forget_address (4). DisconnectPeerResponse.Status reuses its
existing type.

itest: disconnect forget covers all branches — per-address removal,
last-address gating, --forget_node with and without --force against a
channel peer, and both error cases (--force alone; --forget_node +
--forget_address).

Depends on #10975 (which depends on #10973): the itest seeds a second
stored address by reconnecting Alice on Bob's alternate listener, which
#10975's auto-persist captures into LinkNode; it also reads the
remembered_addresses field added in #10973.

Contributes to #10871.

[github-actions]

🔴 PR Severity: CRITICAL

File-based classification | 15 files | 1315 lines changed (722 lines / 10 files excluding tests & auto-generated)

🔴 Critical (4 files)

• server.go - explicit CRITICAL match (server.go — core server coordination); adds ForgetPeerAddress and extends DisconnectPeer signature/behavior
• rpcserver.go - explicit CRITICAL match (rpcserver.go — core server coordination); wires new forget_node/force/forget_address RPC handling
• channeldb/nodes.go - channeldb/* (channel state persistence); new LinkNodeDB.RemoveAddressForPeer mutating persisted peer/LinkNode state
• channeldb/error.go - channeldb/*; new sentinel errors (ErrNodeAddressNotFound, ErrLastPeerAddress) for the above

🟠 High (4 files)

• lnrpc/lightning.proto - lnrpc/*; adds forget_node, force, forget_address fields to DisconnectPeerRequest
• lnrpc/lightning.pb.go - auto-generated from the proto change above (excluded from bump counting, still classified as lnrpc/*)
• lnrpc/lightning.pb.gw.go - auto-generated gateway code (excluded from bump counting)
• lnrpc/lightning.swagger.json - generated API doc reflecting the proto change

🟡 Medium (3 files)

• cmd/commands/commands.go - cmd/*; CLI-side lncli disconnect --forget_node/--forget_address/--force flags
• chanrestore.go - root-package Go file, not matching a listed critical path; minor signature update at a DisconnectPeer call site
• pilot.go - root-package Go file (autopilot glue), not autopilot/* itself; minor signature update at a DisconnectPeer call site

🟢 Low (4 files)

• docs/release-notes/release-notes-0.22.0.md - release notes
• itest/list_on_test.go - test-only change
• itest/lnd_network_test.go - test-only change (new disconnect forget itest coverage)
• lntest/rpc/lnd.go - lntest/* test harness helper

Analysis

The highest-severity files drive this to CRITICAL: the PR directly modifies server.go and rpcserver.go (explicit CRITICAL matches for core server coordination) to add a new ForgetPeerAddress code path and extend DisconnectPeer with forgetNode/force semantics that can delete persisted peer state and, in some cases, force-drop live connections. It also adds new mutating channeldb/* peer-state removal logic (LinkNodeDB.RemoveAddressForPeer) with new sentinel errors — squarely in the CRITICAL "channel state persistence" bucket.

Beyond the base classification, this PR would also qualify for a one-level bump on line count alone: excluding test and auto-generated files, it still changes ~722 lines across 10 files (over the 500-line threshold), and it touches two distinct CRITICAL areas (channeldb/* and core server files) per the "multiple critical packages" rule. Since CRITICAL is already the ceiling, this doesn't change the outcome, but it reinforces that this PR warrants careful expert review — particularly around the semantics of forgetting the last stored address for a channel peer while it remains in the persistent-reconnect set (explicitly called out in the PR description as a subtle edge case), and around the --force gating logic for LinkNode deletion when open channels exist.

The PR is also stacked on top of #10975/#10973, so review should confirm those dependencies land cleanly first.

---

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