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).

Start in crates/registry-evidencectl/src/request.rs at parse_subject_argument and parse_progressive_selector_value, then trace the authoring plan, CompiledSelector, and persisted dev state document mentioned in the issue. Compare the profiled and unprofiled forms and check how documents without selector types are handled. Done means profiled values follow declared field types while the plain shorthand remains lexical, with the documented fallback preserved.

Written by the indexing model from the issue text.