Summary

CLI wrapper for the new issue-links API landed in fangorn/anvil#84. Three subcommands under `anvil issue`:

• `anvil issue links ` — grouped display (blocks / blocked_by / parent / children / duplicate_of / duplicates / related), with redacted tombstones for targets the viewer can’t read.
• `anvil issue link –kind –target ` — create a typed link. `` ∈ `blocks | parent-of | duplicate-of | relates-to`. `` is `#N` (same-repo) or `org/repo#N` (cross-repo).
• `anvil issue unlink <LINK_ID>` — remove by link id.

Test plan

Unit tests on the `#N` / `org/repo#N` parser (8 cases) caught one real bug: `#0` was accepted. Fixed the parser, not the test.

Dogfooded end-to-end against the deployed server:

• `anvil issue links 4` on an empty issue → `(no links)`
• `anvil issue link 4 –kind relates-to –target fangorn/anvil#61` → created cross-repo link
• `anvil issue links 4` → shows the `Related` group with link id + target + state + title
• `anvil issue link 4 –kind blocks –target ‘#4’` → `API error (422): {"error":"self_link"}`
• `anvil issue link 4 –kind blocks –target ‘notahash’` → client-side `invalid –target` before any API call
• `anvil issue unlink 4 ` → removes and `links` confirms empty
• Re-linked fangorn/anvil-cli#4 ↔ fangorn/anvil#61 as a persistent dogfooding artifact (visible on both issues)

Pre-push checks

• `cargo build –release` clean
• `cargo test –release` — 14/14 pass (6 pre-existing + 8 new parser tests)
• `cargo clippy –release –all-targets – -D warnings` clean

Server dependency

Requires fangorn/anvil#84 deployed. That shipped and was deployed before this PR was opened — every item in the test plan was exercised against the live endpoint.

Closes #4