refactor: unify append result-channel delivery on the mailbox model (remove RemoteResultChannel) — no behavior change

[tinswzy]

Summary

This is a pure refactor — it fixes no bug and changes no observable behavior. It removes an asymmetry in how append result channels are delivered, so a whole class of "wrong channel type" mistakes (e.g. the retry bug fixed for #225 / #226) becomes structurally impossible.

There are two delivery models for an AppendOp's per-replica durability result today:

• Single-entry remote (AppendEntry) folds the gRPC stream into the channel: it requires a *channel.RemoteResultChannel, calls InitResponseStream(...), and the channel's ReadResult pulls from the stream via stream.Recv() (common/channel/remote_result_channel.go:132,187; woodpecker/client/logstore_client_remote.go:112-118).
• Batch remote (AppendEntries) keeps the channel as a plain mailbox: a demux goroutine reads the stream and fans each result out via ch.SendResult(...) into per-entry LocalResultChannels (woodpecker/client/logstore_client_remote.go:204-234).
• Embedded (logStoreClientLocal) also treats the channel as a plain mailbox — it just hands it to store.AddEntry, and the store SendResults into it (woodpecker/client/logstore_client_local.go:40,49).

So two of the three paths already use the mailbox model; only single-entry remote embeds the stream in the channel. That single exception is the sole reason RemoteResultChannel (and its type assertion) exists, and the sole reason a channel installed by one path can be the "wrong type" for another.

Proposed change

Unify on the mailbox model: make single-entry remote AppendEntry own the stream read (spawn a reader that Recv()s and SendResults into a plain result channel), exactly as AppendEntries already does. Then:

• The result channel is a plain mailbox everywhere; whether data arrives in-process or over gRPC is the client's concern, not the channel's.
• RemoteResultChannel and the syncedResultCh.(*RemoteResultChannel) type assertion can be deleted.
• The "batch installs a Local channel that a remote retry rejects" failure mode (bug: robustness/correctness gaps in client-side group commit (#208) — retry channel type mismatch, unbounded LAC/batch waits, gRPC stream leak #225 finding Create a running version #1) becomes impossible by construction — the type distinction no longer exists.

Explicitly not in scope / not a bug fix

• This does not fix bug: robustness/correctness gaps in client-side group commit (#208) — retry channel type mismatch, unbounded LAC/batch waits, gRPC stream leak #225 findings Create a running version #1–enhance: Add Scanner Name Support for Continuous Reads and Optimized Lookup #4. Create a running version #1 is already fixed in fix(segment): rebuild per-replica result channel on retry when its type mismatches the client #226; add localfs storage support and optimize fragment management #2/Add website and fix local fs storage bug #3/enhance: Add Scanner Name Support for Continuous Reads and Optimized Lookup #4 have their own PRs. This issue is only about removing the type distinction after those land.
• No behavior change is intended. The retry idempotency property (a matching channel is reused across retries) and all ack/quorum semantics must be preserved. This is a "make the illegal state unrepresentable" cleanup, purely optional.
• Trade-off to weigh during design: the mailbox model adds one reader goroutine per in-flight single-entry send (the pre-batch code effectively already had a per-op receivedAckCallback goroutine, so this is likely a wash, but it should be confirmed, not assumed).

Acceptance

• RemoteResultChannel removed (or reduced to a thin alias) and the type assertion in logStoreClientRemote.AppendEntry gone.
• All existing append/quorum/retry tests pass unchanged (behavior preserved).
• No new config, no API change.

Follow-up to #225. Not blocking any of the #225 fix PRs.