Expose --sequence and --stop_processing_rules on rule-create so callers can control evaluation order and chain-stop for overlapping rule predicates (closes #19, child of epic #17).

[neilgfoster]

What and why

Expose --sequence and --stop_processing_rules on rule-create so callers can control evaluation order and chain-stop for overlapping rule predicates (closes #19, child of epic #17).

Conventions

• Runtime stays stdlib-only, zero-dependency, zero-backend (urllib/json; ruff/pytest are
  dev tooling only).
• No secrets/tokens in the repo — they live outside it in an XDG path (0600).
• Any new/changed skill follows docs/AGENT-FRIENDLY.md (description + CLI I/O are the contract).
• Read-only safety model intact: Mail.Read-only read path, scope ratchet for writes,
  verify-then-install (read-only catch-set), file-to-folder (never delete).

Verification

ruff check . && ruff format --check .
python3 -m pytest -q

• ruff check . and ruff format --check . pass.
• python3 -m pytest -q passes.

[neilgfoster]

plugin/skills/rule-create/SKILL.md:1, plugin/skills/rule-create/SKILL.md:53-60, and plugin/src/msgraph/client.py:187-192 — --stop_processing_rules is documented (in the description frontmatter, argument-hint, and the "Typical flow" example: --sequence 1 --stop_processing_rules) as a bare boolean flag taking no value, but the argparse definition in client.py (type=lambda v: str(v).lower() not in (...), no nargs='?'/action='store_true') requires an explicit following value, matching this codebase's existing convention for --dry_run, --include_hidden, --include_nested (all of which are correctly documented elsewhere as --flag true|false). Concrete failure: an agent follows the SKILL.md example verbatim and runs rule-create ... --sequence 1 --stop_processing_rules, which argparse rejects with error: argument --stop_processing_rules: expected one argument (exit code 2) before the command ever runs — verified by reproducing the identical argparse pattern locally. The doc should read --stop_processing_rules true (and the argument-hint [--stop_processing_rules true|false]) to match the actual CLI contract, consistent with the rest of the plugin's boolean flags.

No other correctness issues found: the --sequence validation (int type via argparse, then isinstance/< 1 check in verbs.py before any Graph call) is sound, defaults preserve prior hardcoded behavior (sequence=1, stopProcessingRules=False), and the new tests correctly exercise default/explicit/rejected paths and assert no network call on the rejected path.