Retire the expected failure on cpp-parity-function-like-macro-expanded-call

[DavidBakerEffendi]

Bifrost v0.10.5 navigates this case correctly, so the annotation asserting it
cannot is stale.

Measured on the 110-case balanced core (see #160):

	v0.10.1	v0.10.5
status	expected_failure	improved
usage→declaration	no_definition, no target	ok → include/parity.h:45:20

45:20 is exactly the expectedDeclaration the case authors. The runner
reports improved precisely for this — a case that passes while annotated as
an expected failure — so the corpus is already flagging it rather than hiding
it.

What to change

Remove the expected-failure annotation from
cpp-parity-function-like-macro-expanded-call in
benchmarks/cases/cpp-lsp-parity.yaml so the case is scored as an ordinary
pass.

Care required

This is reviewed ground truth. The annotation presumably carries a reason
string recording why the case was expected to fail; retiring it should record
that Bifrost now satisfies the authored contract, with the measurement above as
the evidence, rather than silently deleting the note.

Also worth confirming the reference-container run agrees before editing — #160
was measured natively, and native reports label themselves host_specific.

Effect on the freeze

While the annotation stands, a legacy freeze reports one improved case.
That does not block publication — the gates require errors == 0 — but it
means the published result carries a stale expectation.

[DavidBakerEffendi]

This cannot be fixed by editing the case file

I filed this issue proposing exactly that, without checking whether the
document was hash-bound. It is. #166 implemented it and CI rejected it:

Error: historical source document hash changed: benchmarks/cases/cpp-lsp-parity.yaml

benchmarks/promotion/legacy-v1/manifest.json binds
benchmarks/cases/cpp-lsp-parity.yaml at 53719e5f6d247915 and lists
cpp-parity-function-like-macro-expanded-call among its promoted cases.
Removing the annotation moves the file to 9d5a065e1167b8a9, and
validate-legacy-promotion fails at src/promotion.rs:238.

docs/legacy-promotion-manifest.md is explicit that this is the intent, not a
gap:

Corrections are append-only: publish a new promotion ID with a
content-addressed supersedes link. Do not overwrite raw review evidence,
adjudication, the historical YAML, or previously generated result pages. A
replacement is a new reviewed entry in a later manifest and cannot change an
already frozen N.

The cohort was frozen in #124. That it has no published result yet does not
make it unfrozen.

What should happen instead

Nothing, for the v0.3.1 freeze. Leave the annotation. The run reports the
case as improved, which is precisely the designed signal for an expectation
that has outlived the defect it described — the corpus surfaces the staleness
rather than hiding it, without mutating frozen evidence. A published legacy
result carrying one improved case is honest and self-describing.

Retiring the expectation for real means a new promotion ID with a
supersedes link and a fresh reviewed entry — a deliberate act with its own
review, not a cleanup ahead of a freeze.

Revised recommendation

Retitle this to something like "Supersede legacy-promotion-v1 to retire the C++
macro expected failure" and treat it as post-v0.3.1 work, or close it as
working-as-intended and reopen when a superseding promotion is on the table.

Either way it does not block #155. Correcting my earlier note there: the
freeze should expect 11 failures and one improved, and that improved is
now a permanent feature of this cohort rather than something to clear first.