docs: give the last page of the chain its previous link

[lens0021]

Why

Licenses ends the documentation chain and was the one page carrying no {{prevnext}} at all. That was not an oversight in the page — the template had no form for it.

The next page is the last positional argument, so one argument is a next and two are a previous and a next. A trailing empty argument ({{prevnext|Writing an extension|}}) reads exactly like an absent one, so "a previous and no next" was unspellable.

What

That one case gets a name: prev=. Everything else is unchanged, positional and all.

{{prevnext|next step}}
{{prevnext|previous step|next step}}
{{prevnext|prev=previous step}}

Both links resolve from the same two expressions:

previous	{{{prev}}}, or the first argument when a second one follows
next	the second argument, or the first when it stands alone

The previous link renders when either of those is present; the next link renders when there is a page for it. This falls out rather than being special-cased, which is why prev= beside a positional argument still reads as previous and next instead of becoming a fourth form to remember.

Licenses then gets {{prevnext|prev=Writing an extension}}, and the chain runs unbroken from index to it.

Notes

• No layout change needed. A row with one link in it has been the first page's shape all along ({{prevnext|Why wikitext}} on index); a lone previous floats to the other side and the existing overflow: hidden container wraps it.
• No new translation units. A prevnext sits outside the <translate> tags, so it is copied whole into every translation; translate check reports every unit ok, unchanged.
• The template's /doc documents the third form and why it exists.
• Verified by hand against all three call forms; the smoke job bakes the site, which is the real check.

---

Generated by Claude Code

[lens0021]

Not merging this yet: smoke is red, and it is red on the base branch too.

The failure is not this change

The reproducibility assertion fails — two bakes of the same source are not identical — but every rendered page is. The whole of diff -rq dist dist-again is Pagefind output, and only for one language:

Only in dist/pagefind/fragment:       ko_1d4cd71.pf_fragment   (4 ko fragments, all differing)
Only in dist-again/pagefind/fragment: ko_3e638bb.pf_fragment
Only in dist/pagefind/index:          ko_5bc9947.pf_index
Only in dist-again/pagefind/index:    ko_d5117a8.pf_index

-"ko":{"hash":"ko_d4d5ae79da","wasm":null,"page_count":21}
+"ko":{"hash":"ko_badb20c99b","wasm":null,"page_count":21}

en (43 pages) and km (1 page) hash identically across both bakes; ko does not, with the same page count either time. No HTML, CSS, JS, image or webfont file differs. So the input to the index is byte-for-byte stable and the index built from it is not — the instability is inside the index build for that language, not in anything the bake renders.

It predates this branch

Same check, same failure mode, on main at 2e06341 — the commit this branch is cut from (run 32025499955):

-"ko":{"hash":"ko_c8f03edebd", ... "page_count":21}
+"ko":{"hash":"ko_9d8d4c2fd6", ... "page_count":21}

Different hashes than this branch's, because the content differs; identical shape, and en/km stable there too.

This branch adds one link to Licenses and changes a template. Neither can make a stable input produce an unstable index.

What I am doing

Holding this PR. It is three files of documentation behind a red required check that it did not cause, and re-running the job would be asking the same coin to land differently rather than diagnosing anything. When main goes green I will merge the base back in and let CI re-run.

Worth noting for whoever picks up the index: this lands right after #451 (language order between bakes) and #453 (index each language separately), so the language axis is already the suspect, and ko being the only one moving while en and km hold still is the sharpest evidence available so far.

---

Generated by Claude Code