feat: add data-focused UX polish — rich query tables, progress bars, cost badges, schema previews

[anandgupta42]

Add four new TUI components tailored for data engineers:

1. Inline Query Result Tables — Type-aware formatted tables for SQL query
   results with right-aligned numbers, dimmed NULLs, auto-calculated column
   widths that adapt to terminal size, and expand/collapse for large result sets.

2. Query Execution Progress Bar — Live elapsed timer during query execution,
   completion summary with row count + elapsed time + warehouse name, and
   color-coded severity (green < 1s, normal 1-10s, yellow > 10s).

3. Smart Cost Annotations — Inline cost/performance badges on tool calls
   showing row count, elapsed time, truncation status, and warehouse name
   with color-coded severity indicators.

4. Schema-Aware Inline Previews — Rich tree-view schema display with
   short type labels (VARCHAR, INT, TIMESTAMPTZ, etc.), PK/FK detection,
   row count formatting (1.2M, 50.0K), and expand/collapse for wide schemas.

All components:

• Adapt to different terminal widths (tested 20-300 chars)
• Use pure utility functions separated from TSX for testability
• Include 162 tests with 797 assertions covering edge cases,
  screen size matrix, integration pipelines, and error conditions

Also includes GitHub issue template for sparkline sidebar feature.

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[sentry]

Bug: The timer in QueryProgress is initialized only on mount. If the status prop changes to "running" after mounting, the timer will not start.
_{Severity: MEDIUM}

Suggested Fix

To ensure the timer starts when the status prop changes, wrap the timer initialization logic in a createEffect hook. This will make the setup reactive to changes in the isRunning memo, correctly starting the interval as the query status changes.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/opencode/src/cli/cmd/tui/component/query-progress.tsx#L37-L41

Potential issue: The timer initialization logic within the `QueryProgress` component is
not reactive. The `if (isRunning())` check executes only once when the component is
first mounted. Consequently, if the component is initialized with a `status` prop other
than `"running"` and is later updated to `"running"`, the `setInterval` for the timer
will never be called. This will cause the elapsed time display to remain stuck at "0ms"
for the duration of the query, providing incorrect feedback to the user.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[dev-punia-altimate]

🤖 Behavioral Analysis — 4 Finding(s)

🟡 Warnings (3)

• F1 packages/opencode/src/cli/cmd/tui/util/data-table-utils.ts:116 [off-by-one in time formatting]
  formatElapsed uses .toFixed(0) to format the seconds component, which rounds rather than truncates. For any elapsed time in [X*60000 + 59500, (X+1)*60000) — e.g., 119500–119999ms — (ms % 60000) / 1000 evaluates to 59.5–59.999, which .toFixed(0) rounds up to '60', producing '1m60s' instead of '1m59s'. With the 100ms live timer in QueryProgress this bad output appears for 5 consecutive ticks near every minute boundary. The adversarial test suite checks 0ms, negatives, NaN, Infinity, and a 1-day length-only check but misses this case.

• F2 packages/opencode/src/cli/cmd/tui/component/query-progress.tsx:29 [live elapsed timer uses render time not query start time]
  const startTime = Date.now() in QueryProgress is captured at component mount — which is after sql_execute's execute() has already started and Bridge.call is in-flight. The actual query start is at sql-execute.ts:14. These two startTimes diverge by SolidJS rendering latency (50–300ms under normal load). Consequence: the live elapsed timer understates real elapsed time during query execution. When the query completes, display jumps from understated live value to accurate props.elapsedMs from metadata. For sub-2s queries a 200ms understatement is perceptible (e.g. showing '1.3s' live then jumping to '1.5s' at completion). Note: sentry-bot flagged the related but distinct reactive issue (timer won't restart if props.status changes after mount); this is a separate unflagged bug about the reference timestamp.

• F3 packages/opencode/src/altimate/tools/sql-execute.ts:30 [full result rows serialized to SQLite on every SQL query]
  rows: result.rows stores the complete result set (up to args.limit, default 100) in tool metadata. This metadata is JSON-serialized into PartTable.data in SQLite (session.sql.ts:70). The output field already contains a formatted text table for LLM consumption. The rows field is purely for DataTable TUI rendering but is permanently persisted. Effects: (1) every SQL call doubles on-disk result storage; (2) all historical rows are loaded into memory on every session hydrate — message-v2.ts:537–550 reads all PartTable rows unconditionally; (3) data-engineer sessions with many SQL calls accumulate unbounded storage (~24KB per 100-row, 10-col query, JSON-encoded).

🔵 Nits (1)

• F4 packages/opencode/src/cli/cmd/tui/util/data-table-utils.ts:10 — isNumeric relies on !isNaN(Number(s)) && isFinite(Number(s)). JavaScript's Number() parses hex-prefixed strings: Number('0xFF') === 255, Number('0xCAFEBABE') === 3405691582, both pass isFinite. A SQL column with hex string values (checksums, CRC-32, binary IDs) would be classified as type 'number' by detectColumnType, and each cell would be displayed via n.toLocaleString() as a decimal integer — silently replacing '0xDEADBEEF' with '3,735,928,559'. The text output sent to the LLM is unaffected. No adversarial test covers hex input.

_{Analysis run | Powered by QA Autopilot}

[dev-punia-altimate]

✅ Tests — All Passed

TypeScript — passed

Python — passed

_{Tested at 86731aca | Run log | Powered by QA Autopilot}