Allow changing intervalCap at runtime

[vjymisal0]

Summary

Adds a get/set intervalCap accessor on PQueue, mirroring the existing concurrency accessor, so the rate limit can be adjusted after the queue has been created.

Closes #177, which asks for exactly this ("The only thing required for this would be to control #intervalCap property of PQueue at runtime").

Changes

• #intervalCap is no longer readonly; added get intervalCap() / set intervalCap() with the same validation the constructor already does (must be a number >= 1, and must stay finite when strict is enabled).
• #isIntervalIgnored (an internal flag derived from intervalCap/interval) is now recomputed via a small #updateIsIntervalIgnored() helper whenever intervalCap changes, so it doesn't go stale.
• Setting intervalCap calls the existing #processQueue(), so raising the cap immediately lets already-queued tasks start rather than waiting for the next interval tick (same behavior as the existing concurrency setter).
• README: documented that intervalCap can be changed at runtime, and added the .intervalCap entry to the properties list (same pattern as .concurrency).

Testing

• Added enforce number in queue.intervalCap (mirrors the existing enforce number in queue.concurrency test).
• Added queue.intervalCap requires a finite value when strict (mirrors the constructor's equivalent guard).
• Added queue.intervalCap can be changed at runtime, which proves the behavior end-to-end: with intervalCap: 1, only 1 of 4 queued tasks starts; raising intervalCap to 3 immediately starts 2 more without waiting for an interval tick.
• Verified RED/GREEN: reverting just source/index.ts makes the three new tests fail (intervalCap is currently read-only), confirming they exercise the reported gap; with the fix applied, node --import=tsx/esm --test test/*.ts passes all 209 tests.
• tsc and tsd both pass clean with no errors.
• xo currently fails on this checkout with "was not found by the project service" parsing errors on bench.ts and everything under test//test-d/ — verified this is pre-existing and unrelated to this diff (same errors occur on a clean checkout of main with no changes applied), likely an environment/path quirk in this sandbox rather than a real lint issue.

Notes

• interval itself is intentionally left read-only in this PR to keep the change small — it drives timer/window scheduling (#intervalId/#timeoutId) which needs more careful handling to change safely mid-window. Happy to follow up separately if that's wanted too.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vjymisal0]

The Node.js 20 CI run failed on `strict mode multiple complete intervals` in `test/strict.ts`:

```
not ok 193 - strict mode multiple complete intervals
error: 'Interval starting at 0ms has 4 tasks'
```

That test asserts tight 100ms timing windows for strict-mode scheduling and doesn't touch anything this PR changes (it doesn't use the new `intervalCap` setter, and this diff doesn't modify strict-mode tick/timer logic at all — only the read-only-ness of `intervalCap` and the internal `#isIntervalIgnored` recomputation). I ran `test/strict.ts` locally 5x against this branch and it passed every time, so this looks like CI-runner timing jitter rather than something caused by this change. Happy to rebase/retrigger if a maintainer re-runs the job, or let me know if you'd like anything else checked.

[sindresorhus]

Thanks, but I'm not interested in reviewing fully AI generated PRs.