Add runtime switch for Tend workflows

[max-sixty]

Add a top-level enabled setting that each generated job reads before checkout, setup, reactions, or agent execution. Setting enabled: false leaves the workflows installed, skips the rest of each new job, and lets an adopter resume without regenerating.

Operational jobs read the config from the default branch so a PR cannot disable its own review. The one-shot install test reads the PR head because its config has not landed yet. Missing or invalid runtime config fails closed. The generator and runtime gate both accept UTF-8 BOMs and reject YAML merge keys, keeping their decisions aligned. tend check reports when the local config has paused runtime jobs.

Tests: uv tool run pre-commit run --all-files; wt test; packaged-wheel inspection; live read-only Contents API fetch.

This was written by Codex on behalf of max-sixty

[tend-agent]

Verified the gate end-to-end rather than just reading it: extracted the rendered run: body from the snapshots (including the override re-serialization path, where the literal block scalar has to survive a ruamel round-trip or the RUBY heredoc terminator breaks) and ran it against a stubbed gh — enabled: false emits enabled=false plus the notice, a missing config exits 1 with no output so every gated step skips and the job goes red. uv run pytest (903 passed) and all thirteen pre-commit hooks are green, and check-enabled.rb is in the built wheel. Two docs follow-ups, neither blocking.

README.md now uses "enabled"/"disabled" for two different things. The workflow-cadence section still reads "All are enabled by default except ci-fix… Any can be disabled:" over a workflows: weekly: enabled: false block — which omits the file on the next regeneration — while the Configuration section this PR adds says enabled: false "pauses tend from the default branch without removing its workflows". docs/tend.example.yaml got exactly this disambiguation in the same commit ("All workflows are generated by default"; "enabled (bool) — omit this workflow on the next regeneration"), so the README is the one place the old wording survives next to the new key. CLAUDE.md's config bullet has the same phrase ("All workflows are enabled by default") and doesn't mention the top-level switch at all. Happy to push the rewording if you want it.

tend check is what an adopter runs when the bot has gone quiet, and it says nothing about enabled: false — a paused install reports all-green. A line there (or in init's output) would close that loop.

[tend-agent]

Re-reviewed at e205bb9. Both follow-ups from the last pass are closed: the README/CLAUDE.md wording now separates "generated" from the runtime switch, and tend check reports the pause. I re-ran the gate against the shapes the new tests don't cover and found two places where check-enabled.rb's node scan and tend init's ruamel parser disagree — both inline, neither blocking.

One leftover from the terminology sweep, outside the diff: init's empty-set message in generator/src/tend/cli.py still reads No workflows enabled in config. — the one remaining use of "enabled" in the generation sense that docs/tend.example.yaml, README and CLAUDE.md all moved off. No workflows generated from config. matches the rest. Happy to push it if you want it.

What I checked

Ran the parser against inputs outside the new parametrizations — nested enabled under workflows: (correctly ignored), CRLF, flow mapping, !!bool tag, anchored alias, empty file, top-level list, trailing comment. Everything but the two below either agrees with Config.load or fails closed. Confirmed the two proposed patches keep every one of those outcomes unchanged.

Also verified: the literal block scalar and the multi-line if: both survive the ruamel override round-trip (test_extras_apply_path_regtest.out — the RUBY terminator lands at the right column and always()\n&& (...) stays one expression); verify's new permissions: contents: read narrows nothing the check step uses, since that step runs on the bot PAT; setting config_path in cli.init rather than Config.load is right, because the dry-run migration loads from a temp copy whose path must not be baked in.