feat: accept override flag on POST /datasets, shape conflict responses

[Scr4tch587]

Wires the `override` param from the previous PR through the API layer.

What changed:

• `DatasetProposalIn` gains an `override: bool = False` field, passed through to `propose_dataset(..., override=payload.override)`
• `StaleProposalConflictError` now maps to a 409 with a structured body: `{"detail": "...", "conflict_type": "stale_branch", "open_pr_url": "..." | null}`
• the existing dataset-already-registered `ProposalConflictError` also gets `conflict_type: "dataset_exists"` for consistency, but no `open_pr_url` (nothing to show — it's a hard block)

Why: the frontend (next PR) needs a way to tell "this name is permanently taken" apart from "this name is blocked by a leftover branch you can clear," so it only offers a confirm-and-override dialog on the recoverable case.

Benefit: the API surface is ready for the frontend confirm dialog. No user-facing behavior change yet — `override` defaults to `false`, so existing callers see identical responses except for the new `conflict_type`/`open_pr_url` fields alongside the existing `detail`.

[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 👈
        • feat: confirm-and-override dialog for stale proposal conflicts #397
          • docs: document proposal override flow in specs #398