Terminate saveFrames() capture by frame count instead of wall-clock d…

[harshiltewari2004]

Resolves #7958

Changes

saveFrames() used two timers: one capturing a frame every 1000/fps ms, and a
setTimeout that cleared it after duration ms. Because the cutoff was
wall-clock based, a throttled device (battery saver, background tab) fired the
capture interval fewer times inside that window and captured fewer frames than
duration x fps.

Termination is now based on frame count: the capture interval stops itself once
count reaches totalFrames, and the download/callback happens there. The
setTimeout is removed.

This is @HarishVX2's approach from the issue thread — credit to him. The one
difference is ordering: the frame is captured before the count is checked, so
the download fires on the same tick as the final frame. Checking first would
capture one extra frame into the already-cleared array.

Notes

• totalFrames is (duration * fps) / 1000 because duration has already been
  converted to milliseconds a few lines above.
• With duration = 0 or fps = 0, totalFrames is 0, so one frame is captured
  before termination where the old code captured none. Happy to add a guard if
  you'd prefer. I checked in the browser console that setInterval with a delay
  of Infinity (what 1000 / 0 gives) fires immediately, so fps = 0
  terminates on the first tick rather than hanging.

Tests

Added a count assertion in test/unit/image/downloading.js. The existing
saveFrames tests iterate arr.length without asserting it, so they don't
catch this.

Parameters are duration = 0.4, fps = 7.93, giving totalFrames = 3.172.
That fractional value is deliberate: when totalFrames is a whole number the
final tick lands exactly on the old timeout and the result races. With a
fractional target the two implementations differ by exactly one frame every run.

Verified by stashing the source change and re-running: the test fails with
expected 3 to equal 4 on unfixed code, and passes with the fix. Full file:
12 passed.

AI assistance

I used Claude to investigate the timer behaviour and review my approach. I read
the source and traced the race myself, wrote the fix and the test, and verified
both locally.

PR Checklist

• npm run lint passes
• [Inline reference] is included / updated
• [Unit tests] are included / updated

[harshiltewari2004]

Gentle bump — the workflows on this PR and on #9031 are still awaiting
maintainer approval, so the required lint check hasn't run on any of them.
Could someone approve the runs? Both branches are now synced with main
(#9031 also had conflicts from the recent formatting changes, now
resolved). Thanks!

[harshiltewari2004]

Hi @ksen0 I'm so sorry to tag directly — this one's been open about a month and
the workflows are still awaiting approval, so the required lint check
has never run. Would you be able to approve the runs, or point it at
whoever should pick it up?

The sibling PR (#9031) got merged yesterday and touched the same file, so
I've synced this branch with main. Local tests and lint pass. Happy to
address any review feedback whenever someone has time. Thanks!