[factory] Address review feedback on PR #326 (DM inbox scaling limit)

[khaliqgant]

PR #326 (#326, branch fix/relay-1471-inbox-scaling, 'scale DM inbox reads beyond D1 limit') fixes a real production bug (check_inbox/list_dms failing with a SQL 'too many variables' error). Review feedback from cubic-dev-ai unaddressed as of 2026-08-14 06:00Z:

1. (P2, real) packages/engine/src/routes/dm.ts:166 — the new limit query param has no upper bound. Every other paginated endpoint in this engine clamps its limit to 100 (see getDmMessages); this one doesn't, which undercuts the whole point of the PR (unbounded reads blowing past D1's parameter limit). Clamp it to 100, and check whether packages/mcp/src/tools/messaging.ts's schema for this param needs the same cap.
2. (P3, real correctness bug) packages/engine/src/engine/dm.ts:479 — the secondary sort key desc(dmConversations.id) is a lexicographic hash sort (id is dm_ + sha256 hex for 1:1 conversations), not chronological. createdAt is unixepoch() with second granularity so same-second conversations tie, and desc(id) doesn't break the tie by recency. So 'top N' via the new limit isn't guaranteed to be the actual most-recent N. Find or add a real monotonic tiebreaker (rowid/sequence column) — read the schema first, don't guess.
3. (trivial, CodeRabbit nitpick) packages/mcp/src/tests/integration.test.ts:463-467 — the PR's changes replaced a no-argument message.dm.list test case with a limit:25 case, dropping coverage for the omitted-limit path (limit stays optional per openapi.yaml). Add the no-limit case back alongside the new one.

Add tests with a red-check (fail before, pass after) for findings 1 and 2. Existing test suite (dmInboxScale.test.ts, 151 conversations under simulated D1 limit) should still pass. Push to origin fix/relay-1471-inbox-scaling (existing PR branch).

[khaliqgant]

Factory dispatch for 327
Implementers: ar-327-impl-relaycast
Reviewer: ar-327-review-relaycast