[Flotapponnier]

Cherry-pick of #3318 (dev 9c2cbd0) onto main, so the structured-data fix reaches the pages Search Console is actually reading.

19 insertions, one file, zero deletions. src/app/answers/[slug]/page.tsx was identical between main and dev apart from this change, so the pick applied cleanly and nothing main-only moved.

What it fixes

Search Console flagged four recommended fields on an /answers/<slug> page, all on the same node: author and datePublished on mainEntity, and upvoteCount and datePublished on mainEntity.acceptedAnswer. The QAPage wrapper already carried an author and dates; the Question entity Google actually reads for the Q&A result carried none. One URL is reported because one has been crawled as a QAPage so far, and every page in the cluster is built by this same code.

upvoteCount is 0 and stays 0: nothing on this site votes, and Google asks for 0 rather than an omitted field. Any other number would be invented engagement in structured data.

Checks on this base

• pnpm validate 254 specs valid
• pnpm exec tsc --noEmit clean
• pnpm exec eslint clean on the touched file
• bun test 785 pass, 1 fail, and that failure is pre-existing on main, not caused by this pick. See below.

main's CI is already red, since 2026-10-27

src/lib/spec-provider-set.test.ts fails on origin/main with nothing applied: it records f355324b6640e7e4 while main's provider set now hashes to b767efc1bf40bf99. The same test passes on dev, which records its own hash for its own spec set.

The guard is doing its job. Two merges moved a provider set on main after the hash was last updated in #3296, and neither touched the hash or the four cache keys:

• port to main: stop scoring Mobula on Solana in token-quote-coverage (#3310) #3311, token-quote-coverage stops scoring Mobula on Solana, which removes a provider from a set
• port to main: add Perpex as a Hyperliquid builder (#3208) #3312, Perpex joins hyperliquid-frontends, which adds one

Both changed only benchmarks/*.yml. main still carries bench-unfiltered-v102, all-benchmarks-v95, bench-filters-v43 and providers-v21.

In practice the caches have since turned over on their own: production serves 106 providers on hyperliquid-frontends including Perpex. So the exposure window has closed and bumping the keys now would buy a cold cache and nothing else. The remaining problem is only that main's CI is red, which greys out every PR opened against it, including this one.

The fix is one line, updating the recorded hash on main to its current set, and it is deliberately not in this PR: this one is a faithful port of someone else's change, and that one is a decision about cache keys that deserves its own commit message. Say the word and it follows immediately.