docs(governance): a human may ratify a bounded class of change in advance

[vkgeorgia]

What changed

New §2.1 in method/08-governance.md — Ratification may precede the change — the standing grant.

§2's asymmetry ("an agent may propose; only a human may commit the repository to a decision") is about who decides. Read as a rule about when, it forces a false choice: either every instance of a repeating mechanical change waits for a person, or a change is in force with nothing having ratified it. §2.1 states the third case — a repeating mechanical change is usually not a decision each time, but the Nth execution of one decision, so a human ratifies the class ahead of time in a standing grant that names the exact change permitted, the conditions that must hold on every use, and an end condition. An agent acting inside a ratified class executes a decision rather than taking one, and the record of each instance is the run rather than a fresh decision record.

The guarantee is unchanged, and is restated at every point a skimming reader lands so nobody comes away with a weaker one:

• §2's closing rule and §6's summary test now say it directly — every change in force was ratified by a human, the instance or the class, and an agent never supplies that ratification itself.
• §2.1's own bullets: an agent may not author, widen, or ratify a grant (including its own); a change outside every grant falls back to the default of propose-and-wait, because "no applicable grant" is the ordinary case rather than permission; a grant does not travel to another repository, so an adopter inherits the mechanism and never anyone else's grants.
• §4 carries the load-bearing condition: a grant's conditions are in force only where a guard evaluates them on every use, so a grant whose guard is missing has not moved a judgement earlier — it has removed one.

§2's table row for methodology/catalog version upgrades is amended to match.

Two files restated the doctrine in a form §2.1 would contradict, and now point at it instead:

• method/09-releases-and-propagation.md §5 — splits into the default per-instance path (unchanged, including the check-adl.mjs A3 gate) and landing inside a ratified class, with a MAJOR bump or an unmet condition taking the default path.
• method/07-decisions.md §4 — a ratified class needs no per-instance record; the author: agent gate in the table above is untouched, and the grant itself is an ordinary human-authored, human-accepted, immutable record.

How it is verified

• node scripts/check-notations.mjs — clean (20 view notations; examples, internal links, version pins and notation counts consistent). Two pre-existing SIZE1 soft-ceiling warnings on 06-team-operations.md and 07-decisions.md are unchanged: this PR adds one ### subsection and no ## sections.
• node scripts/check-adl.mjs — clean.
• Documentation only; no script, schema, or notation behaviour changes.

Checklist

• Based on main, one concern per PR.
• Commits are signed off (git commit -s) — DCO.
• No hub/work-item references in committed files, this description, or commit messages.