test: de-flake the remaining body.history idempotency assert and bun-proxy abort timing

Two pre-existing flakes surfaced when the 0.1.4 release was pushed
through npm prepublishOnly (build + test) and husky pre-push under host
load:

1. src/request/body.history.test.ts:166 — second idempotency assertion
   in `should handle retry with same body multiple times`. Same root
   cause as the clone-safety test at line 140: two transformRequestBody
   calls race across a millisecond boundary and cch mismatches. Fixed
   with the same vi.useFakeTimers() + setSystemTime dance, wrapped in
   try/finally so real timers are restored for subsequent tests.

2. src/__tests__/bun-proxy.parallel.test.ts:317 — `expect(abortedRequestIds)
   .toEqual([0])` flaked because the test relied on a fixed
   `setTimeout(resolve, 50)` wait after setting `requestTimeoutMs: 25`.
   Under host load (husky running prettier + eslint + vitest + npm
   publish back-to-back) the 25ms abort callback was still in the event
   loop when the 50ms wait expired, so the abortedRequestIds array was
   still empty at assertion time. Replaced the hard sleep with a
   bounded polling loop (5ms granularity, 500ms ceiling) that waits
   for the actual observable state — the abort having been recorded —
   instead of racing a fixed delay.

Both were pre-existing. They did not ship in 0.1.3 because nothing
forced the release path through the stressed host configuration that
exposed them. The 0.1.4 release sequence — which bundled several test
file edits, triggered husky + npm publish back-to-back, and runs with
vitest parallelism — is what surfaced both flakes.

Verification: 5 consecutive full-suite runs, 933/933 each. No timing
sensitivity remaining in either path.