fix(search): return the page a query names, not a heading inside it

[flagendijk89]

Part of MRGFY-8998 — design polish review, August 2026. One of four independent PRs from that pass.

Searching a build tool never returned that tool's page. "bazel" answered
with "Detecting Scopes with bazel-diff", landing the reader past the
"Configuring Manual Scopes" step every one of those pages opens with;
"pants" returned two results and neither was the Pants page.

Two causes, one on each side of the index.

The page-level record held only the intro paragraph and the meta
description, so it was always the thinnest record for its own page and
lost to every heading on it. It now holds the whole page, which lets
relevance decide instead of record size: a page-wide query matches it
across its whole length and wins, while a section-specific query
("barrier files") still goes to the heading, because a short record
dense in those terms outscores a long one where they are diluted. The
if (introBody) guard is gone too — a page with no intro was missing
from the index entirely rather than merely ranking low.

The client then kept one result per URL, first wins, so the winning
heading silently evicted the page record. It now groups a page's records
and lets the page answer when the query names the page.

Also here, all visible in the results list:

• Whole-word title matches sort above incidental ones. "direct merge"
  ranked "Using TestNG Directly" first, matching "Direct" inside
  "Directly" — a match nobody typing those two words meant.
• Rows whose title did not match now carry Pagefind's excerpt. Half a
  result list could otherwise show no highlight and no snippet, with
  nothing on screen explaining why those rows were there.
• Heading permalinks are stripped before indexing. CliCommand.astro
  and Endpoint.astro put a literal "#" inside the <h2>, which is how
  "List a test's executions #" reached the results.
• Changelog titles are demoted alongside their bodies. Demoting only the
  body left every entry's headline at full title weight, so a changelog
  post outranked the page it was announcing.
• Properties sit after the body in each record, so a bare list of config
  keywords stops winning the excerpt over prose.

The full-text page records grow the index 8.7M to 9.0M (+3.4%);
fragments load lazily, so per-search transfer is unchanged.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

---

🤖 Generated with Claude Code

[mergify]

Merge Protections

🟢 All 6 merge protections satisfied — ready to merge.

Show 6 satisfied protections

🟢 🤖 Continuous Integration

• all of:
  • check-success = build
  • check-success = lint
  • check-success = test
  • any of:
    • check-success = test-broken-links
    • label = ignore-broken-links
  • any of:
    • check-success=Cloudflare Pages
    • -head-repo-full-name~=^Mergifyio/

🟢 👀 Review Requirements

• any of:
  • #approved-reviews-by >= 2
  • author = dependabot[bot]
  • author = renovate[bot]
  • all of:
    • author = mergify-ci-bot
    • -head ~= ^docs-agent/

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:

🟢 🔎 Reviews

• #changes-requested-reviews-by = 0
• #review-requested = 0
• #review-threads-unresolved = 0

🟢 📕 PR description

• body ~= (?ms:.{48,})

🟢 🚦 Auto-queue

When all merge protections are satisfied, this pull request will be queued automatically.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-09-05 19:26 UTC · Rule: default · triggered by merge protections
• ✅ Checks passed · on draft merge queue: checking #12689 on main (7d475b8) #12699
• ✅ All checks passed · ready to merge 🚀
• ⏰ Waiting for schedule
• 🔜 Merge · ETA: 2026-09-07 07:00 UTC 🚀