Completions still carry no defaults — and cannot be tested here: no clap_complete dep (open half of #4 finding 3) #9

#4 finding 3 covered two things that a single PR could not close together, and #4 was auto-closed by a
merge before that split was made. #6 fixes one half. This tracks the other.

Fixed in #6 — not this issue

check|graph|review|review-fixtures --help advertise a resolved default again, verified at
18299fe0e by an independent check: --help really does render [default: .] for
check|graph|review and ./15-evaluation/semantic-review for review-fixtures.

Still open — this issue

Completions carry no defaults, and cannot be made to here as the crate stands. There is no
clap_complete dependency in crates/intent/Cargo.toml and no completion generation anywhere in the
crate — the only mention is a doc comment at crates/intent/src/lib.rs:226. So the completions half
of #4 finding 3 is not merely unfixed, it is untestable and unfalsifiable in this repository: any
claim that completions do or do not carry defaults has nothing to run against.

Two things are therefore needed, and they are separable:

1. Decide whether this crate generates completions at all. If yes, that means taking a
   clap_complete dependency and a generator, at which point the defaults question becomes testable.
   If no, #4's completions claim should be recorded as not-applicable rather than left as an open
   defect that cannot be closed by evidence.
2. Host adoption. The consuming repository picks the fixed --help behaviour up only when it
   repins; that is the repin, tracked separately.

Note on --help's displayed default

--help now advertises [default: .], while context/cli/spec.md:63 documents the default as
context/vrs. This is pre-existing — Defaults::default was already . at da5ac9f1b:218-220 — but
#6 made it user-visible. Worth reconciling with the spec in whichever change settles the documented
default; it is a doc/behaviour mismatch, not a regression.