lnwallet: reply to funding requests with a promise instead of channels

[Roasbeef]

Builds on #11151, and is based on that branch so the diff here stays to just
the three commits that are new. Land #11151 first.

In this PR, we get the reply channels out of the internal requests the
LightningWallet message handler serves. Each of those requests used to carry
its own err chan error, and two of them carried a second channel for the value
they answer with, which left every caller draining a pair of channels in the
right order. We hand back an actor.Future instead, following the pattern the
gossiper already uses for ProcessRemoteAnnouncement (see
discovery/gossip_result.go).

The two requests that answer with a value alongside their error use
actor.Promise[fn.Result[T]], so there's no bespoke result struct anywhere:
fn.Result already is the value-or-error type, and callers just Unpack() it
back into the (T, error) pair they had before. The requests whose only answer
is an error keep an actor.Promise[error] behind a small embedded errRequest,
same as the gossiper.

On error types

One thing worth calling out for review, since it's the part that would break
silently. funding.Manager.failFundingFlow decides whether an error is safe to
forward to the remote peer with a plain type switch on
lnwallet.ReservationError, not errors.As. So anything that wraps an error on
its way out of the wallet would quietly turn every reservation error into a
generic one on the wire. fn.Result.Unpack returns the stored error verbatim,
so the concrete type survives, and TestReservationErrorTypePreserved in
lnwallet/wallet_test.go pins that down by running failFundingFlow's exact type
switch over both promise shapes.

Behavior

This is a pure refactor. Every check, error string, and early-return ordering in
the request handler is unchanged, and the awaits use context.Background() so a
caller blocks for exactly as long as the bare channel receive did.

[github-actions]

🔴 PR Severity: CRITICAL

Static analysis | 9 files | 522 lines changed (excluding tests/docs where noted)

🔴 Critical (4 files)

• funding/manager.go - channel funding workflow coordination
• lnwallet/errors.go - wallet operation error definitions
• lnwallet/reservation.go - channel funding reservation / commitment construction
• lnwallet/wallet.go - core wallet operations, channel funding and signing
• lnwallet/wallet_result.go - wallet operation result handling

🟢 Low (1 file, excluded from bump calculation)

• docs/release-notes/release-notes-0.22.0.md - release notes

Tests (excluded from bump calculation)

• funding/manager_test.go
• lnwallet/reservation_test.go
• lnwallet/wallet_test.go

Analysis

This PR modifies core wallet and channel-funding logic (lnwallet/*, funding/*), which directly touches channel funding, commitment/reservation handling, and wallet error/result plumbing — all CRITICAL-tier packages per policy. Non-test/non-generated lines changed total ~522 (over the 500-line bump threshold) and the change spans two distinct critical packages (funding and lnwallet), though this doesn't raise the tier further since CRITICAL is already the ceiling. Recommend expert review from someone familiar with the wallet/funding reservation flow.

---

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