"Always allow" options in consent dialogs now use pre-validated rule rows instead of building rules at click time
Consent dialogs for bash/workflow, file edit, web-domain, and plan-mode actions no longer construct {type:"addRules", ..., destination:"localSettings"} inside the click handler. Each always-allow option now carries a row whose applies array was schema-validated when the option was built; accepting the option just replays row.applies, and if the row is missing or fails validation the handler falls back to a plain one-time allow instead of writing a rule. Array-shaped rule suggestions from the backend pass through a length-capped, trap-safe validator before becoming rows, and mode rows are asserted at build time. The practical effect is that an "always allow" option simply will not appear when the rule it would write cannot be validated locally.
The prompt also gained a yes-apply-suggestions choice, and callers now pass persistRow, suggestionsRow, and standingRowVetoed through. Several older rule builders, including the skill's yes-exact/yes-prefix builder and the file-edit claude-folder scope branch, were removed.