fix(gate-35): an image named by its context is not a lie

[rubenvdlinde]

gate-35 flags alt="" on a src whose expression carries a content noun. That
shape is usually the "I made gate-31 green by lying" tell — but it is also
the shape of correct markup:

<a :href="item.link">
  <img :src="item.thumbnailUrl" alt="">
  <h4>{{ item.title }}</h4>
</a>

The link takes its accessible name from the heading, the image is decorative,
and alt="" is exactly what WCAG H67 asks for — giving the image its own alt
makes a screen reader announce the headline twice.

There is no waiver for gate-35, so the only ways out were to write a worse alt
or rename the variable to dodge the noun list. Both are worse than the finding,
which is why this is a gate change rather than an app change.

What changed

The noun test still decides which images are suspicious. This adds a second
question: does the markup around it already name it? An image inside <a>,
<button>, <label> or <figure> is exempt only when that ancestor carries
text besides the image.

Kept deliberately narrow, because widening is how this gate goes blind:

• only those four elements — a <div> wrapper names nothing and still fires
• the text must be inside the ancestor — a sibling link does not excuse an
  image outside it
• a link whose only content is the image still fires, because then the
  image is the link's only possible name and alt="" leaves it nameless

Evidence

launchpad @ development, NewsWidget.vue lines 45 and 77 — both inside a link
named by its own <h4>, both reported, no waiver available.

Verification

check	result
unit tests	46 pass
the 5 new exemption tests against the pre-fix checker	fail — they bite, rather than describe
acceptance CLEAN arm	0 findings, incl. new NamedByContext.vue whose 4 images the old checker flagged all 4 of
acceptance PLANTED arm	all 10 still reported, incl. new NounsLinkOnly.vue anti-widening case
test_gate_a11y_helper_wiring.sh	70/70
test_gate_a11y_markup_scope.sh	ALL PASS

Not in this PR

gate-7's two launchpad findings (preview, searchSharees) are also false
positives — neither method takes an object id, so neither has an IDOR surface.
But gate-7 already provides @no-admin-idor-exempt <reason>, and its own
comments warn that widening its guard patterns "would let gate-7 clear real
IDORs". So that one gets the sanctioned waiver in the app, not a code change here.