docs(readme): lead with the engine's own banner, and stop calling a shipped backend planned

[DemchaAV]

Why

The engine deck contradicted itself on its own first page. The Output Backends
column listed PPTX as Planned, next to a version badge reading v2.1.0 — the
release that shipped it, and the release whose copy of that very deck is published as
engine-deck.pptx. The page also called the library one for "structured business PDF
documents" and ended its pipeline at "PDFBox writes the bytes", both written when PDF was
the only output.

That first page is also, by design, a banner — it is literally the deck's Banner
section — and the composition to render it standalone already existed behind
EngineDeckExample.renderBannerImage, cropped tight, no page chrome, straight to a
raster through the image backend. It wrote to nothing the repository kept. Meanwhile
README opened with a 300px logo.

What

• EngineDeckData.backends(): PPTX becomes the live @Beta backend, ordered ahead of
  the semantic-only DOCX export. Tagline and pipeline step 4 cover both formats.
• README leads with that banner, linked to the PDF of the same composition.
• GenerateAllExamples now renders engine-banner.pdf as well. Without it a committed
  engine-banner.pdf would be a preview nothing refreshes — which the drift gate
  refuses, correctly. Now the release re-renders it like every other preview.
• New "The engine, explained by the engine" section: the deck, the twin PDF/PPTX
  pair, the feature catalogue, the master showcase and the Maven Central banner.
• Benchmark snapshot refreshed to a five-run median; both decks and their layout
  baselines re-rendered.

renderBannerImage's Javadoc claimed to be the source of
repository_showcase_render.png. It is not, and has not been since the module-first
EngineDeckV2Example took that over — cut-release.ps1 re-renders the module-first hero
through ReadmeBannerV2Renderer. The two heroes are different compositions with
different jobs, and the Javadoc now says which is which.

On the numbers

None of the deck's prose needed changing for the new data, which is what drawing it from
the result file is for. Each claim verified against the fresh median:

Claim on page 4	Fresh data
"the time lead over iText widens"	2.38x at 40 rows → 3.50x at 200 → 4.25x at 1000
"JasperReports closes to roughly the same render time at 1000 rows"	38.5 ms vs 40.0 ms — 4% apart
"stays markedly lighter on memory than both rivals throughout"	2.5–2.7x vs Jasper, 3.0–3.5x vs iText

At 1000 rows Jasper renders marginally faster in this run and the deck's chart shows it.
Same picture the previous snapshot painted (64.08 vs 64.77 ms, GraphCompose ahead by 1%)
— parity either way, inside a run-to-run spread that ranged 0.72x–1.03x across the five.

Every library also got ~1.65x faster than the July snapshot while peak heap moved under
1%. GraphCompose cannot speed up iText or JasperReports, so that is the machine, not the
code — worth knowing before reading perf-smoke's "IMPROVED" verdict against a baseline
captured on the older state.

Tests

./mvnw -B -ntp clean verify → BUILD SUCCESS.

• CommittedAssetDriftTest named the two previews that moved — engine-deck.pdf and
  engine-deck-v2.pdf — and confirmed maven-banner.pdf did not.
• Both deck layout baselines updated deliberately after diffing them: the only structural
  change is the tagline growing from one line to two (13.4pt → 28.1pt) and the sections
  below shifting by that height. No node added, removed or retyped.
• The catalogue was rendered with -Dgraphcompose.examples.displayVersion=2.1.0. Without
  it a render off develop prints 2.1.1, a coordinate nobody can resolve; that pin is
  what examples/pom.xml holds the drift gate to.
• Every relative link and image path in README resolves, checked mechanically.

[DemchaAV]

Reverted — the ask was different: keep maven-banner as it is and give it the remaining pages, in the shape engine-deck has. Reopening as a fresh change.