Live-hint/menu value-domain awareness: valid values flagged invalid & invalid constrained values not flagged

[carldebilly]

Summary

Follow-up from the review of #55 (raised by autocarl, explicitly non-blocking). After #55 the interactive live hint no longer flags a pending option value as Invalid when the current token is one the parser would consume as a separate value (empty, a plain value, or a signed numeric literal). That is correct for free-form (string) options.

But for a constrained pending option — today an enum — a consumable but non-matching prefix now shows no candidate and no Invalid hint, even though execution will reject it.

Repro

app.Map("run", ([ReplOption] ProbeMode mode) => mode.ToString()); // enum { Debug, Release }

> run --mode Z   (Tab)
# no enum candidate (nothing starts with "Z") AND no "Invalid: Z" hint
# execution would reject Z (enum parse fails)

Contrast: run --channel --prod (dash-prefixed, not consumable) correctly keeps its Invalid hint, and run --channel alpha (free-form string) correctly suppresses it.

Why it is deferred

• Purely a live-hint UX nicety — it does not change execution or completion-candidate correctness.
• Getting it right means the hint has to know the option's value domain and whether the typed prefix can still reach a valid value. That generalizes beyond enums (regex/type-constrained parameters, providers that constrain their output), so it deserves its own design rather than an enum special-case.

Suggested direction

Carry the pending option's parameter (already resolved on the completion path) into hint construction, and only suppress the Invalid fallback when the option is genuinely unconstrained (or when the prefix can still complete to a valid value). Add interactive regression tests for: free-form value (no hint), dash-prefixed value (Invalid), enum non-matching prefix (Invalid), enum matching prefix (candidate shown).

Context

• Introduced by the hint-suppression fix in fix(autocomplete): option-value & option-region completion parity edges #55 (AutocompleteEngine.BuildLiveHint, pending-value branch).
• Sibling of the option-value/option-region parity work in Completion suggestion vs execution parity: option-value & option-region edges (follow-ups from #50) #54/fix(autocomplete): option-value & option-region completion parity edges #55.

[carldebilly]

Broadening scope — the #55 re-reviews surfaced two more cases of the same root gap (the live hint / invalid-alternative menu does not understand an option's value domain or free-form validity). None affects execution or the actual completion candidates; all are Invalid hint/menu label cosmetics.

Direction 1 — valid value flagged invalid (should be neutral):

• show --answer:foo — once the user types past the bare --answer: prefix, the literal no longer prefix-matches, so completion returns nothing and the token is labelled (invalid). But GlobalOptionParser.TryParsePromptAnswer accepts any --answer:* case-insensitively. --answer:* should be treated as neutral/valid (like help <path> free-form text).

Direction 2 — invalid constrained value not flagged (should show Invalid):

• run --mode Z (enum), run --count abc (int) — the token is consumable as a value, so the invalid hint is suppressed, but execution fails value conversion. Constrained options should keep Invalid: … when the value cannot bind.

Suggested direction: carry the pending option's parameter into hint/menu construction and decide the label from the value domain — unconstrained/free-form (incl. --answer:*) → neutral; constrained (enum, numeric, validated) → Invalid when the value cannot bind.

Deferred from #55 (kept converged); autocarl approved with this class open, Codex flagged both directions as P2 but they are non-blocking hint cosmetics.