feat: structured tool call metadata and worktree project normalization

[wesm]

Summary

• Extract and persist structured tool call metadata (tool_use_id, input_json, skill_name, result_content_length) from session files into the tool_calls table
• Pair tool_result content lengths back to their originating tool_call via tool_use_id in the sync engine, then filter empty user carrier messages
• Expose structured tool_calls in the message API response and enrich frontend tool block rendering with parsed arguments (Bash commands, Task prompts, TaskCreate/Update metadata, Skill names, etc.)
• Canonicalize worktree project names during import so archived worktree sessions group with the main repository even when worktree paths no longer exist on disk
• Batch tool-call hydration queries to avoid SQLite bind-variable limits on large sessions

Test plan

• All Go tests pass (CGO_ENABLED=1 go test -tags fts5 ./...)
• All frontend tests pass (380 tests)
• Worktree project normalization: online worktree, offline worktree with branch hint, offline worktree without branch
• Tool-call batch hydration across batch boundaries (500+25 messages)
• Manual: open a session with tool calls, confirm tool blocks show arguments and no empty user messages appear

🤖 Generated with Claude Code

[wesm]

cc @clkao — this superseds your PR since I rebased and pushed some other stuff

[roborev-ci]

roborev: Combined Review (551c7dc)

Summary Verdict: The PR introduces several High and Medium severity issues, primarily involving the
potential exposure of sensitive tool arguments, a missing database column causing runtime SQL errors, and logic bugs in project extraction and content parsing.

High Severity

1. Sensitive Tool Inputs Exposure

• Files: internal/parser/content.go:49, internal/db/messages.go :27, internal/db/messages.go:252, frontend/src/lib/utils/content-parser.ts:202, frontend/src/lib/components/content/ToolBlock.svelte:103
• Description: Raw tool inputs
  (input_json) are extracted, stored, returned in API payloads, and rendered in the UI (including multiline commands and prompts). These inputs commonly contain secrets (tokens, passwords, private paths), significantly expanding the credential exposure surface.
• Suggested Remediation: Redact sensitive fields/flags before persistence (
  token, password, authorization, -p, --api-key, etc.), store only allowlisted fields for display, and gate full input_json behind explicit privileged access (or disable by default).

2. Missing Database Column Runtime Error

• Files: internal/db/ messages.go (around line 407)
• Description: The query uses ORDER BY id on the tool_calls table, but the schema for tool_calls does not define an id column. This will cause a SQLite syntax error (no such column: id) during runtime.
• Suggested Remediation: Use ORDER BY rowid or explicitly add an id primary key column to the tool_calls table schema.

Medium Severity

1. Unintentional Tool Metadata Exposure

• Files: internal/db/messages .go:100, internal/db/messages.go:123
• Description: GetMessages(..., includeContent bool) and GetAllMessages always call attachToolCalls, regardless of the includeContent flag. If callers rely on includeContent=false for reduced/safe output, sensitive tool arguments can still be exposed via tool_calls.input_json.
• Suggested Remediation: Respect the content/redaction mode for tool_calls as well (skip attaching, or attach only non-sensitive metadata when includeContent=false).

2. Out-of-Bounds Panic in Branch Suffix Trimming (DoS)

• Files: internal/parser/project.go (around line 204)
• Description: trimBranchSuffix slices the original string based on the byte length of a lowerc
  ased suffix. Because strings.ToLower can alter the byte length of certain Unicode characters, len(name) - len(suffix) can become negative, causing an immediate runtime panic or malformed UTF-8. A malicious actor can trigger this panic via session logs.
• Suggested Remediation: Locate
  the suffix boundary using case-insensitive methods that return the correct byte index in the original string, use a case-insensitive regular expression, or use strings.TrimSuffix(strings.ToLower(name), ...) if preserving casing is not strictly necessary.

3. Incorrect Project Git Root Fallback

Files: internal/parser/project.go:73, internal/parser/project.go:105

• Description: ExtractProjectFromCwdWithBranch always tries findGitRepoRoot(cleaned) first. When cwd no longer exists, find GitRepoRoot falls back to filepath.Dir(cwd) and may latch onto an unrelated parent git repository on the current machine, overriding the intended branch-suffix fallback.
• Suggested Remediation: Only probe the git root when cwd itself exists (or at least when the path can be validated
  ), otherwise skip directly to basename + trimBranchSuffix.

4. Incorrect Bash Orphan-Fragment Absorption

• Files: frontend/src/lib/utils/content-parser.ts:227
• Description: In enrichSegments, Bash orphan-fragment absorption uses
  fullCmd.includes(next.content.trim()). This substring match can incorrectly drop legitimate following text segments that happen to be substrings of the command.
• Suggested Remediation: Absorb only a strict continuation fragment (e.g., prefix/suffix-based matching against the expected remainder), rather than any
  substring match.

---

Synthesized from 4 reviews (agents: codex, gemini | types: default, security)

[wesm]

These findings are false positives, merging!