Don't start a pipeline for an issue whose dependencies aren't closed yet

# Goal

When the owner asks to start work on an issue that declares a dependency on another issue that isn't closed yet, Radical Pipelines surfaces those open blockers before starting, instead of silently beginning blocked work out of order.

# Constraints

- **Opt-in, non-breaking.** Declaring dependencies is not mandatory. An issue (or a project) that declares none starts exactly as it does today.
- **Tracker-agnostic.** The check works through the project's **Issues** convention — it must not hard-wire one tracker's mechanics. Trackers with native dependency support use it; others fall back to a generic mechanism.

# Context

- This project's topology (`.rp.md`): **GitHub is the source of truth** (via `gh`); **Linear is a status-only mirror** whose issue descriptions hold only the GitHub URL. Because the Linear mirror is intentionally content-free, GitHub is the only place a dependency can authoritatively live here.
- **Dependencies should be legible to people, not just the gate.** A human triaging the backlog benefits from seeing what's blocked and what's startable, so the representation should stay visible to readers rather than hidden metadata. Native relations give this for free (GitHub's Relationships sidebar and a "Blocked" badge on the issues list; Linear's blocked/blocking flags); a fallback should keep the dependency visible in the issue itself.
- Native support now exists on both trackers: GitHub issue dependencies (GA Aug 2025) and Linear issue relations. `gh` has no native dependency flags yet (cli/cli#11757), so GitHub reads would go through `gh api` / REST.
- Precedent: #11 (warn before orchestrating an issue with existing PRs) is the existing "check first, pause for explicit owner confirmation" pattern.
- Sibling work on issue relationships: #89 (suggest follow-up / related issues at close-out) and #103 (search related/duplicate before creating). This is the dependency-ordering relative of those.
- The **Issues** convention is currently single-tracker (`skills/radical-pipelines/reference/conventions/setup.md`, the "Issues (required)" section) and has no notion of dependencies.

# Assumptions / directions to explore

_(open, not requirements)_

- The check most likely lives at the start of `work-on-an-issue.md`, when the issue is identified and before a pipeline is created or dispatched.
- Follow the #11 pattern: stop and surface the open blockers, and let the owner explicitly choose to proceed — a gate with an override, not a hard refusal.
- Reading dependencies could be a new capability on the **Issues** convention: **native where the tracker supports it** (preferred — human-visible in the tracker UI and machine-readable at once; GitHub `blocked-by` via `gh api`), and a **generic fallback** otherwise — a _visible_ marker line in the issue description (e.g. `Blocked by: #NN`) that `create-pipeline.md` strips **from the derived `0-prompt/prompt.md` only**, leaving it visible in the issue for human readers. Leaking the marker into the prompt is a minor, fully-mitigated concern, not a hard boundary.
- "Closed enough" predicate: a blocker counts as resolved when its issue is closed (GitHub) / in a Done-or-Canceled state (other trackers).
- Best-effort / fail-open: no declared dependencies → proceed; unable to determine (no native support, unparseable marker) → proceed, perhaps with a note — never freeze work.
- The gate reads exactly **one authoritative tracker** — the issue source of truth (GitHub here). Mirroring blocked state into Linear, and the broader "primary issue tracker vs. progress mirror" modeling in `setup.md`, are separate downstream increments, out of scope for this.
- A dependency pointing outside the authoritative tracker (e.g. a Linear-only roadmap item with no GitHub issue) is informational only — surfaced, owner decides — since pipelines key off GitHub issue numbers.

Start at work-on-an-issue.md, then read the Issues convention in skills/radical-pipelines/reference/conventions/setup.md and the prompt derivation in create-pipeline.md. Compare the existing check-and-confirm pattern from #11 and inspect how GitHub reads could use gh api. Done means open blockers are surfaced with an explicit override, while missing or unreadable dependency data fails open and dependencies remain visible to readers.

Written by the indexing model from the issue text.