fix(time): return a plain zero for sub-half-frame negative durations

[renezander030]

Summary

Follow-up to #81. framesFor returns negative zero for durations smaller than half a frame in the negative direction, because Math.round(-0.03) is -0 and the us > 0 floor guard in framesAtRate does not catch it.

framesFor(-1_000, 30)       // -0
quantizeToFrame(-16_000, 30) // -0

Nothing breaks downstream — JSON.stringify(-0) is "0" and the value compares equal under == and === — but assert.strictEqual(framesFor(-1_000, 30), 0) throws, because node:assert/strict compares with Object.is. That is a trap for whoever writes that test first, and it is invisible until they do.

framesAtRate now branches on the zero case once and returns a plain 0, which reads clearer than the + 0 normalisation trick and keeps the one-frame floor exactly where it was.

Validation

• The new test fails RED on a8d31e3 with expected: 0, actual: -0, and passes with the fix.
• npm test — 666 tests, 666 passed, 0 failed.
• npm run lint — 125 files, no warnings or errors.

No behaviour change for any positive duration: the five measured #69 rows, the one-frame floor, the 30 fps fallback, and the signed result for -100_000 are all untouched.

No CHANGELOG entry — the helpers are still under ## [Unreleased] and never shipped with the -0, so the existing bullet already describes what the release will do.

Part of #82; the draftToOtio deduplication in that issue is still open.