add-epic --link silently accepts malformed format; update-epic has no --link setter to fix it

[cfdude]

Summary

Two related gaps in epic-link handling:

1. add-epic --link accepts a malformed link value silently. A --link argument that doesn't match the expected format is not validated — the command exits 0 and the epic is created with a bad/no-op link rather than erroring. The user gets no signal that the link didn't take.
2. update-epic has no --link flag to set/fix a link. Once an epic exists with a missing or malformed link, there is no supported way to correct it via update-epic. (Related: update-epic: no --lane flag, and clearing links relies on undocumented valueless --link #66 notes clearing links relies on an undocumented valueless --link, but there is no documented way to set a valid link.)

Impact

A typo or wrong format in add-epic --link is unrecoverable through the normal CLI surface: the bad value is accepted without complaint at creation time, and there's no update-epic --link to repair it afterward. Users fall back to hand-editing .conductor/state.json, which the conductor treats as the state of record and is exactly what the CLI is meant to avoid.

Expected

• add-epic --link <val> should validate <val> against the accepted link format and fail loudly (non-zero exit + message) on a malformed value, instead of silently accepting it.
• update-epic <id> --link <val> should exist as a documented setter to add/correct a link on an existing epic, with the same validation.

Context

• Commands involved: add-epic, update-epic
• Surfaced while triaging the conductor backlog in cfdude/cfdude-plugins (this was tracked there as the planned epic pm-fix-link-flag-validation-and-update); filing here since pm's code now lives in cfdude/pm.
• Related: update-epic: no --lane flag, and clearing links relies on undocumented valueless --link #66 (update-epic missing --lane; undocumented valueless --link for clearing).