🐛 Bug Report — Runtime APIs: setAlarm

## Description

**`setAlarm(Date.now())` issued from inside `alarm()` behaves inconsistently and never fires promptly.**

- In local workerd (`miniflare/vitest-pool-workers`) the re-set alarm is silently cleared when the running alarm handler completes, permanently severing an alarm chain.
- In production DOs it is retained (`getAlarm()` returns the past-due timestamp) but does not fire for tens of seconds, if at all, until the object is next disturbed.

**Note**:

`setAlarm(Date.now() + 1)` works correctly in both environments.

## Minimal repro

A Durable Object whose `alarm()` increments a counter and re-arms with `setAlarm(Date.now())`.

Expected: either both environments fire the past-due alarm promptly, or the API documents that re-arming at/behind the current time from inside `alarm()` is unsupported.

Actual: counter stalls at 1.

Work-around: with `setAlarm(Date.now() + 1)` it chains normally.

Start with the minimal Durable Object reproduction using alarm(), setAlarm(Date.now()), and getAlarm(), then compare behavior in local workerd via miniflare/vitest-pool-workers with production DOs. Done means re-arming at the current time either fires promptly and preserves the alarm chain in both environments, or the API explicitly documents this case as unsupported.

Written by the indexing model from the issue text.