fix: recover stale source peer that breaks forwards with CHANNEL_INVALID

[awdr74100]

Problem

A forward source referenced by numeric channel id — a private channel
with no @username, e.g. -1001727806995 — can only be forwarded from
when the session storage holds a full, non-min access hash. That hash
is only obtainable via a dialog scan (getDialogs), and it silently decays
to min between runs. resolvePeer cannot recover a full hash on its own
for such a peer (it falls back to channels.getChannels with a zero access
hash → CHANNEL_INVALID).

The result: after restarting (classically "the next day"), every forward
from that source fails with CHANNEL_INVALID on repeat, and the only fix
was to manually re-run group add / group edit — whose only effective
action is the dialog scan they happen to perform (group remove does not
touch the peer cache at all). checkPeers already warmed the cache, but
only conditionally, and its resolveState first pass cannot tell a decayed
min hash from a good one — so it skipped the scan and the forward failed.

What changed

Two layers, both boiling down to "make sure the source is warmed to a full
access hash":

• Start-time warm (checkPeers). Warm the cache unconditionally on
  start whenever any source/target is a private numeric channel (marked
  -100…), instead of trusting a resolve that can look valid yet still fail
  the real forward. A username-only setup resolves over the network and
  still skips the scan.
• Runtime self-heal (forwardOne + recoverSource). When a forward
  fails with an invalid-peer error, probeTarget disambiguates: if the
  target still resolves and was not migrated, the bad peer is the source
  — so re-warm the cache once and retry. The scan is throttled to one per
  SOURCE_WARM_COOLDOWN_MS (60s) so a burst of failing forwards cannot
  launch a dialog scan each (which would risk FloodWait). Because the queue
  is serialized, the first message's warm usually repairs storage and the
  rest succeed on their first attempt. No more manual group edit.

The existing basic-group → supergroup target migration path is
unchanged; source recovery slots into the branch that previously just
re-raised the error.

Details

• forwarder.ts:
  • checkPeers: force a warm when any peer is a private numeric channel.
  • forwardOne: on a healthy target, attempt source recovery + retry.
  • add recoverSource (throttled dialog-scan warm) and lastSourceWarmAt.
  • add isPrivateNumericPeer helper and SOURCE_WARM_COOLDOWN_MS.
  • rename isInvalidTargetError → isInvalidPeerError (it now classifies
    invalid-peer errors for both source and target).

Tests

• isInvalidPeerError: renamed; existing coverage retained.
• checkPeers: username-only setup still skips the scan; a new test
  asserts a private numeric channel always warms even when it resolves
  cleanly from cache.

pnpm typecheck, pnpm lint, pnpm test (62 passed), pnpm build, and
pnpm knip all pass.

Note: recoverSource orchestration inside forwardOne is not directly
unit-tested (it requires driving a real Dispatcher + RPC, which this repo
deliberately does not mock). The pure logic it relies on is covered, and
the diagnosis was verified against the real session.sqlite (source
stored isMin=1, no username, no usable message reference).