automations: rename AutomationRun.resultPreview → result (with migration)

[mgoldsborough]

Context

PR #329 dropped the 500-char cap on automation run output. The field that holds the output — AutomationRun.resultPreview — was named for the preview shape and now misleads: it stores the full deliverable. The field's docstring in src/bundles/automations/src/types.ts notes the back-compat reason for keeping the name:

/** Final agent response. Field name kept for backward compatibility with
 *  existing JSONL records; current writes store the full response. */
resultPreview?: string;

QA review on #329 flagged this as the cleaner end-state work for after the PR lands.

Goal

Rename AutomationRun.resultPreview → AutomationRun.result everywhere, with a migration so existing on-disk run records continue to read correctly.

Scope

Source sites that mention resultPreview (find via grep -rn 'resultPreview' src/):

• src/bundles/automations/src/types.ts — field declaration + docstring
• src/bundles/automations/src/executor.ts — mapResultToRun() writes the field
• src/bundles/automations/src/server.ts — status / runs tool handlers shape the response
• src/bundles/automations/ui/src/components/RailItem.tsx — rail snippet derived from it
• src/bundles/automations/ui/src/components/RunRow.tsx — expanded view renders it
• src/bundles/automations/ui/src/components/ReaderPane.tsx — main reader renders it
• src/bundles/automations/ui/src/components/AutomationDetailView.tsx — test-run result renders it
• web/src/_generated/platform-schemas/automations.d.ts — regenerated via bun run codegen

Migration

Existing run records live as JSONL append-only files at {workDir}/users/{userId}/automations/runs/{automationId}.jsonl. Each line has resultPreview for older records and would have result for new writes. Three options, increasing safety:

1. Read-time shim (simplest): store.readRuns reads either field, prefers result when both present. Old records read fine; no on-disk migration needed. Cost: indefinite carry of the back-compat code path.
2. One-shot migration script (bun run migrate:automation-runs-result-rename): rewrites every JSONL line, swaps the key. Idempotent; safe to re-run. Same .migration-lock convention as existing scripts (migrate:user-creds, migrate:files-to-identity, etc.). Run during a maintenance window. After deploy, the code only knows result.
3. Both: run the migration script during deploy AND keep the read-time shim for one release as belt-and-suspenders.

Recommend (2) with the script following the existing migration runbook pattern. Document the operator step in the relevant section of CHANGELOG and the Stage runbook so production tenants run it during the maintenance window.

Why this wasn't done in PR #329

The rename touches ~10 files plus a migration script and an operator runbook step. Mixing migration-level work into PR #329 — which already shipped a kernel primitive + UI refactor + 4 QA rounds — would have multiplied the review surface and the regression risk. QA review on #329 explicitly classified this as 'future rename is the cleaner end state'.

References

• PR Automations: Task primitive + V3 reader + mobile pass #329 (feat/automations-ux)
• src/bundles/automations/src/types.ts field comment
• Existing migration script pattern: scripts/migrate-user-creds.ts, scripts/migrate-files-to-identity.ts