[Bug] /opsx:verify accepts a near-equivalent heading as the REMOVED baseline, so a replacement requirement is reported as still implemented #2098

Summary

Since the fix for #2067, /opsx:verify reads the baseline of a REMOVED requirement from the main spec before searching the codebase. The new text accepts a "near-equivalent" heading as the baseline. When the REMOVED requirement has been replaced by a similarly named ADDED requirement and /opsx:sync has already updated the main spec, the near-equivalent heading is the replacement, not the removed requirement. The verifier then searches for the replacement's behavior, finds it, and reports the removed requirement as still implemented.

Version

@fission-ai/openspec 1.14.2, Claude Code delivery (skills + commands), spec-driven schema.

Where

.claude/commands/opsx/verify.md, step 5 Spec Coverage, the "For each REMOVED requirement" bullet that begins "If that file holds no such requirement under this or a near-equivalent name", and the mirrored .claude/skills/openspec-verify-change/SKILL.md. In the package the text comes from dist/core/templates/workflows/verify-change.js.

The bullet before it already says to match "by normalized name"; the "near-equivalent" wording in the next bullet contradicts that and decides the fallback to history.

Repro

1. Main spec has ### Requirement: Monthly export in xlsx.
2. A change has a delta with ## REMOVED Requirements for Monthly export in xlsx and ## ADDED Requirements for Monthly export in xlsx as attendance sheet.
3. /opsx:sync is run, so the main spec now holds only Monthly export in xlsx as attendance sheet.
4. Run /opsx:verify.

Expected: the exact normalized REMOVED heading is absent from the main spec, so the baseline is recovered from the file's git history (the removed requirement's own body and scenarios), and the search is for that behavior.

Actual: the replacement heading counts as a near-equivalent name, so its body is used as the baseline. The code legitimately implements it, so the removal is reported as not done.

Why it matters

The failure is a false "still implemented" on a removal that was done correctly, driven by a legitimate pattern (replace a requirement by a more specific one). It only appears after a sync, which is exactly the case the history fallback was added for.

Suggested fix

Match the REMOVED heading by its normalized name only. If the main spec has no requirement with that normalized heading, go to the history fallback; do not accept a similarly named heading. If a rename is involved, that is the RENAMED operation's job.