fix(core): cancel stale debounce timers - #70430

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features) — N/A, no public API or documented behavior changes

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

When debounced() is given a numeric wait, the setTimeout scheduled on each source
change is never cancelled. Superseded timers stay queued until they fire, at which point
the active === result guard discards their result. The resource reports the correct
value, so there is no incorrect state — but the timers outlive their usefulness:

• A timer still pending when the injector is destroyed stays queued for the remainder of
  its delay, retaining its callback closure and the captured value. In a fakeAsync test
  this fails the spec with 1 timer(s) still in the queue., which is what a consumer hits
  when a component holding a debounced() is torn down mid-wait.
• Rapid source changes queue one timer per change instead of one per wait window. Each
  surplus timer wakes up only to be discarded by the guard.

Issue Number: N/A

What is the new behavior?

The pending timer is tracked and cleared once it becomes obsolete, in three places:

• when a newer value supersedes it,
• when the source throws and the resource enters the error state,
• when the injector is destroyed.

The timer id is also released when the timer fires, so a completed timer is never cleared
afterwards — in a browser its id may already have been reused by an unrelated timer.

Cancellation deliberately happens after the equality check that returns early, so a
value that is equal to the one already pending leaves the running timer counting down.
This is why the cleanup is explicit rather than done through the effect's onCleanup:
the effect re-runs whenever the source notifies, including for equal values, and
cancelling on that path would kill a live debounce with nothing rescheduled, leaving the
resource stuck in loading.

No public API or observable state transitions change.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Four specs were added under a timer cleanup block in debounce_spec.ts. Three of them
fail without the fix:

They assert on clearTimeout via a spy, comparing timer ids by identity — in Node a timer
id is a Timeout object, which no deep-equality matcher should try to serialize.

Verified with:

pnpm test //packages/core/test/resource:resource

70 specs, 0 failures with the fix; 3 failures on the parent commit.