dep: label-backed cross-project dependency surface (add/rm/ls/gc)

[PerishCode]

Why

Plane's native work-item relations do not cross projects, but real dependencies do (e.g. a plane-cli command depends on a Plane-server api/v1 endpoint). We need a way to record and query cross-project dependency edges today, without waiting on server-side support.

What

plane dep — a top-level surface that stores dependency edges as dep:<KEY>:<SEQ> labels on the dependent item (an item carrying dep:PLANE:5 is blocked by PLANE-5). Labels are the durable, queryable edge store; the CLI is the CRUD + query layer.

• plane dep add --project P --work-item ID --on KEY:SEQ — validate the target exists (forward references are rejected), ensure the dep:* label (reserved color), and attach it. Attach is a read-modify-write of the item's labels, since the API replaces the whole set.
• plane dep rm ... --on KEY:SEQ — detach the label; the label object is kept.
• plane dep ls --project P [--work-item ID] — parse dep:* labels, resolve each target via GET work-items/KEY-SEQ/, print the name or flag dangling; --json.
• plane dep gc --project P [--write] — delete orphan dep:* labels (labels no item carries); dry run unless --write.

commands/api/dep.rs + wiring; skills/plane-cli/references/api.md documents it. DAG diagnosis (plane dep doctor) is deferred to a follow-up.

Tests

cargo fmt --all --check                                          -> clean
cargo clippy --locked --workspace --all-targets -- -D warnings   -> clean
cargo test --locked --workspace                                  -> 68 passed (21 + 47)

Unit tests cover --on/label parsing and label-id extraction. Live-verified against a real workspace: add + idempotency, forward-ref + bad-format rejection, ls resolution, and the rm → gc-dry-run → gc --write orphan-cleanup cycle all pass.

Trade-off worth flagging

• Edges live in the label namespace (the only cross-project, queryable primitive Plane exposes). gc prunes orphan labels so the label list stays equal to the live edge set. Native cross-project relations remain the long-term server-side fix.