test(coord-gateway): mcp.test.ts "get_events 支持 since 续传" 反复出现时序竞争型 flaky（已命中两次）

## 现象

`apps/coord-gateway/test/mcp.test.ts:168` 的用例「get_events 支持 since 续传」在 CI 上反复出现时序竞争型 flaky——本轮（#814 review）与 #816 review 各命中一次，重跑后均转绿，非改动引入的真实回归。

```ts
it("get_events 支持 since 续传", async () => {
const all = await callTool("get_events", { limit: 500 });
const events = all.data["events"] as Array>;
expect(events.length).toBeGreaterThan(0);
const last = events.at(-1)!["event_id"] as string;
const tail = await callTool("get_events", { since: last });
expect((tail.data["events"] as unknown[]).length).toBe(0);
});
```

同一 describe 块内前面的用例（`claim_issue`/`get_realtime_status`/`get_ready_work` 等）都会往同一个 RepoHub DO 实例写事件，怀疑是共享状态下事件写入与本用例读取之间存在时序竞争——取到 `last` 之后、`since=last` 查询之前，如果又有新事件落地（比如 vitest 并发跑其他 it block，或 DO 内部有异步落盘延迟），`tail.data.events` 就不会是空数组，断言失败。

## 建议

两个方向二选一（或都做）：
1. 给这条断言加合理的重试/轮询容忍（不是无脑 retry 掩盖真实 bug，而是显式等待"事件流稳定"后再断言 since 续传为空）。
2. 排查这条用例是否应该用独立/隔离的 DO 实例，避免和同 describe 块的其他用例共享可变状态导致的时序竞争。

## 来源

coord-main 在 #814 review 中指出："这个 mcp.test.ts 的 flaky 已经反复出现两次了（#816 review 也踩过），值得单独开个 issue 把它本身修掉，免得以后每次卡在这里都要走一遍'诊断是不是flaky'的流程。"

Start with apps/coord-gateway/test/mcp.test.ts:168 and read the surrounding describe block, especially the event-producing tests and shared RepoHub DO setup. Run this test repeatedly in CI-like conditions, then determine whether explicit polling or an isolated DO instance removes the race. Done means the since continuation assertion remains reliable without hiding a real regression.

Written by the indexing model from the issue text.