feat: prices on pages, a currency switch, a cart page and variants in the admin

[JasonYv]

Stacked on #5, which moves to mallok@0.1.0-rc.11. Review that one first; this one's diff is against its branch. Merge it after #5, by fast-forward, so that these commits keep their ids.

What this is

Phase 1B of the design (docs/superpowers/specs/2026-09-30-nundar-on-mallok-design.md, §12 and the new §17): the part of the catalogue that waited for Mallok's plugin API 2. Four things are built on it, with nothing worked around.

	What a visitor or a seller gets
Prices on pages	Each size on a product page with its price, minimum order, availability and lead time; what each product starts at in the finder and the catalogue; the same offers in the page's Product structured data
A currency switch	US dollars on English pages, euros on the others, and a switch to any currency the page has prices in
A cart	A form beside each size, and a cart page in the site's own design and language: set a quantity, remove a line, choose a currency. No script anywhere in it
Variants in the admin	A form under each product's editor for variants, prices and stock, with a ledger of every stock change

How it works, in short

• The shop plugin declares "pluginApi": 2 and a renderData hook. While Mallok renders a page, one batch of two statements reads the variants and prices of the products shown; the theme prints them, and the page is cached with them. A cold product page is three D1 round trips.
• A page carries a cache tag for each product it prices. A save in the admin, and a repricing run, purge the tags of the products they changed.
• A page says whether a size can be had, never how many are left.
• GET /_mallok/p/shop/cart is the cart page, drawn by the theme's shop/cart layout. POST …/cart/update is where every form posts; it only ever redirects. A change the shop refuses is sent to the cart page, which says what was refused.
• A public page is the same for every visitor: nothing about a cart is in it, and the cart's cookie goes only to the shop's own routes.

The commits

Commit	What it does
feat: show each size's price…	The renderData hook, the page data, the theme's rows, the structured data, the cache tags
feat: add a currency switch…	A third declared script; the sample gains euro and sterling prices
feat: add a cart page…	The two cart routes, the cart layout, the add-to-cart forms, the header's link
feat: edit variants, prices and stock in the admin	The records panel and its handlers, the delete hook, purging on change
docs: record what phase 1B built…, docs: bring the security notes up to date…	Design §17 and SECURITY.md
three fix: commits and a docs:	What an independent review found (below)

An independent review, and what it found

The finished work was given to a second reviewer with the properties it must hold and no account of how it holds them. It found eleven defects and seven smaller things. Each was checked before it was acted on, and each fix has a test that fails without it. The three that mattered most:

• An open redirect. The path a form may send the buyer back to was judged by the text sent; /.//host is one slash as typed and another site once resolved.
• A derived price left over from the wrong base price when two saves of one variant crossed.
• An expired cart coming back with the next thing added, and a cart id a visitor could choose.

The rest are listed in the design's §17, with the one suggestion that was looked at and not taken.

How it was verified

Check	Result
npm run lint, npm run typecheck, npm run build	Pass
npm run test:project	52 of 52
npm run test:shop	633 of 633 inside workerd, 184 of them new
npm run smoke, npm run smoke:shop, npm run preview -- --check	Pass on a real local Worker: a product page's form posted as it stands, a refused quantity followed to the page that explains it, the cart read in English and German, a variant added and deleted the way the admin's form does
Red and green	209 deliberate breakages: 202 turned a test red, five change nothing a caller can observe, two showed checks that could never fire, which were removed
In a browser, by hand	A buyer's path clicked through; the admin's variant form opened and saved; every page of the sample, and the cart pages with three lines in them, at thirteen widths from 320 to 1920 px
Each fix: commit	Passes lint, the type check and every test on its own

The measuring found one regression before it was committed: with the cart's link in it, the header's one line ran past the page's edge at 1280 px in three languages. The gap between its links is tighter where that line begins.

Not verified

• Nothing was deployed. No CPU figure on a real account, and whether a purge actually evicts a page there, are both unknown. Of phase 1's exit criteria, those two are not met.
• No automated browser test exists. What the currency switch does to a page, and the layouts, were checked by hand in one engine.
• Nothing was tried with a screen reader. The new German, French and Spanish strings were not read by a native speaker.

Not built

• The cart leads nowhere yet: it cannot be sent as one inquiry, and there is no checkout. Whose the inquiry cart is to build is a decision this pull request does not take.
• Prices beside the products a collection page lists. Mallok tells a plugin what a list shows and not what a content page lists through a reference. A test here holds that state and fails the day it changes.

For the owner to decide

• A cart line may hold at most 10,000, a limit carried over from the previous implementation. A catalogue of small parts may want more.
• A derived price is rounded up to the next .99, which turns $1.60, $1.85 and $2.05 alike into €1.99. The sample uses hand-entered prices instead.