evidencectl request: parse the profiled --subject value by the selector's declared type

The `role@profile:field=value` form of `--subject` (`parse_subject_argument` in `crates/registry-evidencectl/src/request.rs`) hands its value to `parse_progressive_selector_value`, the progressive typed parse. A string selector value that looks numeric or boolean (a registration code `00123`, the word `true`) is sent typed, and the runtime refuses it as mistyped. The escape is the JSON-quoted form (`code="00123"`), which no help text or tutorial names. The unprofiled `role:field=value` form keeps its value lexical.

The progressive form has no local project and must keep the rule. The profiled form does not need it: the compiled project knows every profile's field types.

Options:

1. Thread the selector field types from the authoring plan through `CompiledSelector` and the persisted dev state document (with a default for documents written without them) into a type-directed parse for the profiled form. Recommended.
2. Keep the rule and document the quoted escape in the `--subject` help (regenerating the CLI reference) and in the BReg tutorial.

Either way the plain shorthand stays lexical. Not a trust boundary: the runtime's selector validation refuses the mistyped value before any source call.

Origin: review of PR #865 (raised by Codex, answered in-thread).

Inizia in crates/registry-evidencectl/src/request.rs, in parse_subject_argument e parse_progressive_selector_value, quindi segui l’authoring plan, CompiledSelector e persisted dev state document menzionati nell’issue. Confronta le forme profiled e unprofiled e verifica come vengono gestiti i documenti senza selector types. Il lavoro è completato quando profiled values seguono i declared field types, mentre il plain shorthand rimane lessicale e viene mantenuto il fallback documentato.

Scritto dal modello di indicizzazione a partire dal testo della issue.