refactor(web): reduce pending send pruning complexity

[Yevanchen]

Closes YEF-882

Summary

• Indexed user messages by trimmed content before pruning optimistic pending sends.
• Added coverage for same-content baseline messages followed by a new echoed user message.

Why

• The previous pruning path scanned every message for every pending send and repeatedly checked baseline ids.
• This reduces the hot-path echo detection from a broad pending x messages scan to a single user-message index plus cheap per-pending lookups.

Verification

• Commands:
  • vp exec bun test apps/web/tests/agent-session-pending-sends.test.ts
  • vp run --filter @mosoo/web tc
  • vp run --filter @mosoo/web lint
  • vp run --filter @mosoo/web test
  • vp fmt --check --ignore-path .gitignore apps/web/src/routes/agent/components/agent-session-pending-sends.ts apps/web/tests/agent-session-pending-sends.test.ts
  • python3 $CODEX_HOME/skills/complexity-optimizer/scripts/analyze_complexity.py apps/web/src/routes/agent/components/agent-session-pending-sends.ts --format markdown
• Manual steps: N/A
• Not run: Full repo vp run -w check.

Impact

• User/API/contract changes: N/A
• Generated files / GraphQL / DB / lockfile: N/A
• Env or config changes: N/A
• Risk and rollback: Low; behavior is covered by the existing pending-send tests and the new same-content baseline regression case. Roll back the single commit if needed.

Review

• Closest review areas: apps/web/src/routes/agent/components/agent-session-pending-sends.ts
• Known trade-offs: The index is rebuilt per prune call; this keeps state local and avoids cache invalidation risk.