fix(bridge): require plan.md step ticking, closing the verify §7 blind spot

[AdrianTheopold]

Problem

The apply-phase executor rule named tasks.md only, while plan.md ships - [ ] **Step N** boxes from its own template (templates/plan.md) and no instruction ever asked for them to be maintained. The READMEs reinforced this in both languages, framing progress tracking as tasks.md's job and plan.md as micro-steps with no tracking role.

Observed live: a full cycle ticked tasks.md conscientiously in the same message as every SDD ledger line and left all 20 plan.md step boxes empty. The rule was followed for the file it names and missed for the file it does not.

The stale ledger is the lesser half. Verify §7 reads plan.md for [~] deferred rows, to make "deferred-and-gapped" visible at archive. An unmaintained plan.md silently disarms it:

• a manual/dogfood step genuinely deferred during apply never gets marked [~];
• §7 then renders legitimately blank and the cycle reports "no deferrals" when it had them;
• §7's blocking condition (empty §7 AND [~] rows present) cannot fire either, because the rows it looks for were never written.

So this is a correctness hole, not bookkeeping tidiness. It went unnoticed because the cycle that exposed it happened to defer nothing.

Changes

• apply step 2 — the executor ticks both committed ledgers in the same bookkeeping step as the SDD ledger line, and marks a step [~] at the moment it defers it. Both failure modes are named, because neither reads as bookkeeping on its own. Also states the meta-reason: a rule written for one of two committed files gets followed for that one and missed for the other.
• verify §7 — a blank §7 counts as "nothing deferred" only if plan.md was actually maintained; otherwise reconstruct the deferral state from the SDD ledger and the commits, tick plan.md, and re-run.
• README.md + README.zh-TW.md — correct the framing that assigned progress tracking to tasks.md alone. tracks: tasks.md names what OpenSpec parses, not the whole bookkeeping duty.
• VERSION 1.1.0 → 1.2.0, plus the release line in both READMEs.

The version bump is load-bearing for the install tooling, which compares version strings: a changed bundle left at 1.1.0 reports "up to date" while every consuming repo still resolves the old instructions — silent drift behind a green readout.

Verification

• openspec schema validate superpowers-bridge → valid
• openspec schemas lists the bundle and its artifact chain unchanged
• Repo conventions followed: English schema.yaml/templates, English conventional commit, both README locales synced, validated against a throwaway project per CLAUDE.md's documented flow

Context

This is H1 of the fold-in list, reopened and widened — the v1.1.0 correctness pass (#1) fixed the tasks.md half; the plan.md half was never in scope.