docs(config-cascade): add Implementers rows for the source-control and work-items YAML team layers #7196

Problem

docs/conventions/config-cascade/README.md "Implementers" (line 525) is the registry of tracked consumer config. Two surfaces that #7009 touches have no Implementers row for their docs/conventions/*.yaml layer:

• docs/conventions/source-control.yaml, key pr_open_state (schema plugins/source-control/schemas/source-control.schema.json:10; resolution order in plugins/source-control/reference/config-resolution.md:157-164). The existing source-control row (line 541) lists only .claude/source-control.md.
• docs/conventions/work-items.yaml, the triage keys triage_repro_count and triage_objection_window_hours (schema plugins/work-items/schemas/work-items.schema.json:10-16; read by /work-items:triage only, plugins/work-items/skills/triage/SKILL.md:137-138). The existing work-items rows (lines 553-554) list only .work-item-tracker.json and .github/recurring-schedule.json. The file itself is not tracked in this repository yet, so the row records a layer that is absent here.

The registry does not say who reads or writes these files, which layers apply, or whether they conform.

Validator check (scripts/validate-plugin-contracts.mjs:108-110,126-160,228): a plugin named in a backticked token of an Implementers row's first column is treated as owning tracked consumer config, and its setup skill may not use the check-only carve-out. source-control and work-items are already in the table, so new rows change no validator result. Both setup skills already offer apply (plugins/source-control/skills/setup/SKILL.md:3, plugins/work-items/skills/setup/SKILL.md:3). Neither apply writes the new YAML files today (neither setup SKILL.md mentions docs/conventions/source-control.yaml or docs/conventions/work-items.yaml), so a row that claimed a setup writer would run ahead of the code. The rows must say the file is hand-edited until setup gains a write step.

Fix

Add one Implementers row for each file, in the existing row shape (path, layers, who wins, merge form, conformance, keys, reader, writer). For source-control, pr_open_state resolves per config-resolution.md:157-164 (argument, userConfig, then team YAML; an unknown value never opens a PR ready). For work-items, the team layer beats the plugin's userConfig (schema description). If the rows change the generated semantics table, edit it to match; CI's --check step verifies it, and add Root-rule-by-surface entries if the readers anchor differently.

Done when

• The Implementers table has a row for docs/conventions/source-control.yaml (pr_open_state) and one for docs/conventions/work-items.yaml (triage keys), each stating reader, writer, layers and conformance as they stand on main.
• If the rows change the generated semantics table, the table is edited by hand to match.
• CI's check-plugins job (which runs scripts/validate-plugin-contracts.mjs) and lint-repo job (which runs scripts/sync-config-cascade-semantics.py --check) pass on the PR (a PR check; this run does not run it).

Refs: #7009