Normalize tool calls for mobile sync: apply_patch as paired CodexPatch diffs

[bra1nDump]

Context for reviewers new to this area

Happy Agent syncs its sessions to the Happy mobile app (slopus/happy, packages/happy-app) as encrypted messages. The mobile app renders tool calls keyed by tool name, with purpose-built views for a fixed set of names (Edit, CodexPatch, Bash, …). Anything it does not recognize falls back to a generic card.

The principle this PR establishes, recorded in sources/happy/LEARNINGS.md: normalize on the producer side. Happy Agent translates its internal tool calls into the shapes mobile already renders well, so mobile clients never need to parse provider-specific formats (like Codex's apply_patch grammar) and older app builds keep working without updates.

Where things live:

• packages/happy-agent-modules/sources/happy/ — the mobile sync bridge: session client, message mapping, pairing.
• sources/happy/mapHappyMessages.ts — maps internal session events to mobile wire messages.
• sources/happy/normalizeHappyToolCall.ts (new) — per-tool translation into mobile's renderable shapes.

What changed, commit by commit

1. 2b8c2147 — Improve Happy tool sync semantics. Tool-result events carry the actual result and error flag to mobile instead of content: null (the counterpart optional fields exist in the app's schema; both sides treat them as optional, so old ↔ new combinations keep working).
2. dccf4f72 — Normalize apply_patch for Happy mobile. Codex apply_patch calls are parsed inside Happy Agent and sent as mobile's established CodexPatch { changes } payload.
3. 4baf45e2 — Normalize Happy tools for mobile wire. Extracts the translation into normalizeHappyToolCall.ts and generalizes it beyond patches, with its own test suite.
4. a613ca73 — Render Codex patches as paired mobile diffs. Update hunks go out as modify: { old_content, new_content } rather than a raw unified diff string. Mobile routes that shape through the same paired, intra-line-highlighted diff renderer it uses for Claude Edit; a raw patch string would send it down a simpler prefix-colored fallback.

Compatibility

• All emitted shapes (CodexPatch { changes }, modify { old_content, new_content }) are ones released mobile apps already render — that is the point of producer-side normalization.
• New optional fields on tool-result events are stripped by older app schemas; nothing breaks in either direction.

How to test

pnpm --filter @slopus/happy-agent-modules exec vitest run tests/happy

272 tests, all passing. Normalization coverage is in tests/happy/normalizeHappyToolCall.test.ts and tests/happy/mapHappyMessages.test.ts.

Related work

Consumer-side counterpart in the mobile app: slopus/happy#1731 — renders all edit tools as expanded inline diff ribbons, keeps agent questions inline, and documents the tool-rendering registry. That PR's CodexPatchView renders exactly the changes shapes this branch produces.