fix(web): give a preset card its own code, lead with the catalogue, and draw a link preview for the shape a link preview is

[DemchaAV]

Why

Four things a visitor meets on the showcase home page.

A preset card showed code that draws a different preset. The catalogue carries one
compiled block per family — the CVs' builds BoxedSections, the invoices' ModernInvoice —
and every other card of the family was shown it, captioned From the docs. The caption was
honest; the code under it still drew another design, and that is what a reader copies.

The catalogue sat below the install block and a format-by-format comparison, so the page
asked a visitor to add a dependency before showing them anything the library draws.

The line above the catalogue promised a PDF on a click. A viewer opens.

og:image named a portrait page of one proposal, 893×1263. A large-image card is
landscape, so X cropped a band out of its middle and published a paragraph of a document
nobody had asked about, under a link about the library.

What changed

• A preset card carries the smallest block that draws its own preset, built from what the
  card already states — presetClass and dataModel — in the form that preset's own runnable
  example uses: the no-argument create(), which carries the preset's theme rather than
  another's. The family's block stays on the one card it composes; the link to the page it is
  published on stays on all of them.

  It is not that block with its composing line rewritten, and the invoices are why:
  ConsultingInvoice takes StructuredInvoiceDocumentSpec where the block builds
  InvoiceDocumentSpec, so a rewrite would hand a reader a record the preset does not accept.
  Checked before writing it: all 56 preset classes in the catalogue expose a no-arg create().

• The catalogue follows the opening block, ahead of install and formats. Every id and
  anchor is unchanged, so existing links and shared viewer addresses land where they did.

• The intro says what a click does — the viewer, what it pages through, and what it links.

• SiteSocialCoverRenderer composes a 1200×630 cover with GraphCompose itself (a page
  declared in points, rasterised at 72 DPI, so the PNG is exactly that size), in the site's own
  palette, carrying the existing showcase/logo.svg wordmark, Document generation for Java,
  and three documents read from web/showcase/thumbnails/ — the previews the catalogue
  publishes, so the cover cannot show a template the site does not have. No version, no
  measured figure: it outlives the release that published it. Published at
  web/assets/social/graphcompose-cover-2026-09.png, a name of its own, because Slack, X and
  LinkedIn cache a preview by URL. twitter:card stays summary_large_image; both tags now
  declare the size, the type and an alt text. A document's own page keeps its own preview —
  there the document is the subject.

Verification

• node scripts/site/gallery-viewer.test.mjs, build.test.mjs, home.test.mjs — all pass.
  Two cases asserted the old contract and were rewritten to the new one rather than deleted:
  the family block is now expected on the card it composes, and a case was added for the card
  it does not.
• node scripts/site/build.mjs --check — the committed web/ is what web-src/ builds.
• ./mvnw test -pl :graph-compose-core -Dtest='ShowcaseSiteGuardTest,ShowcaseCardInstructionsTest,ShowcaseSnippetScopeTest,ShowcaseBundledFontClaimTest,VersionConsistencyGuardTest' — 42 tests, 0 failures.
• ./mvnw test -f qa/pom.xml -Dtest=DocumentationExamplesTest — 12 tests, 0 failures.
• On the generated page of a preset the block does not compose: Compose this preset,
  BlueBanner.create(), and zero occurrences of BoxedSections. On the one it does:
  Compose it, unchanged.
• The cover was rendered, opened and looked at. The first pass put the third document 48 points
  past the right edge — a layout no assertion would have caught, and the reason the fan's
  geometry is now derived from the page width with the arithmetic written down beside it.

After merge

GitHub Pages redeploys on push to main. The platforms cache by URL, and the URL is new, so
the first scrape after deploy gets the new cover. To confirm rather than assume:

• X — Card validator
• LinkedIn — Post Inspector
• Facebook/Meta — Sharing debugger, Scrape again
• Slack unfurls by URL too; a link posted in a channel where it was shared before may need
  ?v=2 appended once to force a re-unfurl.