feat: confirm-and-override dialog for stale proposal conflicts

[Scr4tch587]

Wires the stale-branch conflict info from the API into the create-dataset form.

What changed:

• `ApiError` gains an optional `body` field carrying the parsed error response, so callers can read structured fields beyond `detail` (previously only the string `detail` was ever surfaced)
• `DatasetProposalPayload` gains `override?: boolean`, passed through on resubmit
• on a 409 with `conflict_type: "stale_branch"`, the form shows a confirm dialog (same pattern as the build panel's real-build confirmation) naming the open PR if there is one, and resubmits with `override: true` on confirm
• a `conflict_type: "dataset_exists"` conflict is unaffected — still just the existing inline error box, no override offered, since that case is a hard block

Testing: `bun run typecheck`, `bun run lint`, `bun run format:write`, and `bun run build` all pass. Smoke-tested the form in a scratch dev server (Chrome) — renders and opens with no console errors; the actual 409 trigger needs a live backend to exercise end-to-end, covered by the backend-layer tests in the earlier PRs in this stack.

Benefit: re-testing/re-proposing a dataset name whose earlier proposal PR was closed without deleting the branch no longer requires a human to manually clean up the branch via the GitHub API/UI — the form surfaces it and lets the user recover in place.

[github-actions]

• main
  • feat: add branch/pr cleanup methods to GitHubClient #394
    • feat: distinguish dataset-exists vs stale-branch conflicts in proposals #395
      • feat: accept override flag on POST /datasets, shape conflict responses #396
        • feat: confirm-and-override dialog for stale proposal conflicts 👈
          • docs: document proposal override flow in specs #398