fix(conversations): add required seq to ToolTimelineEntry test fixtures (fixes red main, #4948)

[M3gA-Mind]

Summary

• main is currently RED — the Frontend Checks (quality, i18n, docs, coverage) lane fails to typecheck, which hard-blocks every open PR. This restores it.
• Adds the now-required seq: 0 field to the two ToolTimelineEntry test fixtures in app/src/pages/__tests__/Conversations.render.test.tsx (lines 2414 and 2438).
• Test-fixture-only change — no production code and no behavior change.

Problem

main fails tsc --noEmit with two TS2741 errors:

src/pages/__tests__/Conversations.render.test.tsx(2414,21): Property 'seq' is missing in type
  '{ id: string; name: string; round: number; status: string; }' but required in type 'ToolTimelineEntry'.
src/pages/__tests__/Conversations.render.test.tsx(2438,21): (same)

Root cause — a semantic conflict between two individually-green PRs:

• fix(conversations): key the proactive-thread insights fallback (disclosure state leak) #4944 (b48b62327) added two new ToolTimelineEntry fixtures to Conversations.render.test.tsx.
• fix(flows): stable issue-order for tool-call timeline (monotonic seq + FIFO result pairing) #4945 (4a68fd727) made seq: number required on ToolTimelineEntry (app/src/store/chatRuntimeSlice.ts:286) and updated 12 test files to add seq — but it was authored against a base predating fix(conversations): key the proactive-thread insights fallback (disclosure state leak) #4944, so it never saw these two fixtures.

Both passed CI in isolation; once both landed on main, the two fixtures lack the newly-required seq and the typecheck lane breaks. Full writeup in #4948.

Solution

• Added seq: 0 to each of the two fixtures, placed after round and before status — matching fix(flows): stable issue-order for tool-call timeline (monotonic seq + FIFO result pairing) #4945's own convention for every comparable single-entry fixture it updated (timeline/selectors.test.ts, SubMascotLayer.test.tsx, ToolTimelineBlock.test.tsx).
• Repo-wide verification that fix(flows): stable issue-order for tool-call timeline (monotonic seq + FIFO result pairing) #4945 didn't miss any others: grepped every ToolTimelineEntry-shaped object literal in app/src and confirmed the only strictly-typed ones missing seq were these two. All other round:+status: literals surfaced by the sweep are either as-cast to a looser param type (ChatRuntimeProvider.test.tsx, WorkflowCopilotPanel.test.tsx) or belong to loosely-typed mock/snapshot fields, so they do not require seq. Definitively confirmed by a clean full tsc --noEmit after the fix (0 errors).

Submission Checklist

If a section does not apply to this change, mark the item as N/A with a one-line reason. Do not delete items.

• Tests added or updated (happy path + at least one failure / edge case) per Testing Strategy — updates existing test fixtures so the suite compiles; no new behavior to cover.
• Diff coverage ≥ 80% — changed lines are within existing, executed test bodies; N/A for new production lines (none added).
• Coverage matrix updated — N/A: test-fixture-only change, no feature rows affected.
• All affected feature IDs from the matrix are listed in the PR description under ## Related — N/A: no feature behavior changed.
• No new external network dependencies introduced.
• Manual smoke checklist updated if this touches release-cut surfaces — N/A: test-only.
• Linked issue closed via Closes #NNN in the ## Related section.

Impact

• CI/build only. Restores the Frontend Checks typecheck lane on main, unblocking every open PR (notably feat(core): compile-time flows feature gate (#4797) #4912, feat(core): compile-time skills feature gate (#4798) #4913, feat(core): compile-time mcp feature gate (#4799) #4914, fix(build): forward tokenjuice-treesitter + gate feature-forwarding drift in CI (#4918, #4919) #4934).
• No runtime, platform, performance, security, migration, or compatibility impact — the change is confined to a *.test.tsx fixture.

Related

• Closes: main fails typecheck: ToolTimelineEntry fixtures missing required seq in Conversations.render.test.tsx #4948
• Unblocks: feat(core): compile-time flows feature gate (#4797) #4912, feat(core): compile-time skills feature gate (#4798) #4913, feat(core): compile-time mcp feature gate (#4799) #4914, fix(build): forward tokenjuice-treesitter + gate feature-forwarding drift in CI (#4918, #4919) #4934 (all blocked by red main)
• Follow-up PR(s)/TODOs: none

---

AI Authored PR Metadata (required for Codex/Linear PRs)

Linear Issue

• Key: N/A
• URL: N/A

Commit & Branch

• Branch: fix/GH-4948-tooltimeline-seq-fixtures
• Commit SHA: 1e43cc4182d3643e59b37f46f38eb61767d9c89e

Validation Run

• pnpm --filter openhuman-app format:check — not run (two-line fixture edit; keys placed to match surrounding style).
• pnpm typecheck — passes clean (0 errors); this is the exact lane that was red on main.
• Focused tests: not run locally (test-fixture-only, type-level fix); CI runs the affected suite.
• Rust fmt/check (if changed): N/A — no Rust changed.
• Tauri fmt/check (if changed): N/A — no Tauri changed.

Validation Blocked

• command: N/A
• error: N/A
• impact: N/A

Behavior Changes

• Intended behavior change: none.
• User-visible effect: none — restores CI only.

Parity Contract

• Legacy behavior preserved: yes — fixtures assert identical runtime behavior; only the required seq field was added.
• Guard/fallback/dispatch parity checks: N/A.

Duplicate / Superseded PR Handling

• Duplicate PR(s): none.
• Canonical PR: this PR.
• Resolution: N/A.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1a683b1b-c319-43eb-9b62-76ef84f0ebb8

📥 Commits

Reviewing files that changed from the base of the PR and between 69fef4a and 1e43cc4.

📒 Files selected for processing (1)

• app/src/pages/__tests__/Conversations.render.test.tsx

---

_{Comment @coderabbitai help to get the list of available commands.}