Serve the unchanging files from one table

[theAndreas]

Stage C of lifting the web front end into firmware/, cut deliberately narrow: the asset table, not the dispatch.

What moved

The five files a clock hands out unchanged — the two pages, the manifest, the two icons — had a handler each, in both backends. Ten functions differing only in a blob, a content type, and whether a Content-Encoding header went with it. That is data, so it is WebFrontend::AssetType now, walked by each backend to register one route per entry.

The bytes moved with it, and that part mattered: WebPage.h is generated with internal linkage, so a second includer means a second copy of both pages in flash. It is included by WebFrontend.cpp and nothing else; neither WebInterface.cpp includes it any more.

Where the backends genuinely differ, and how each solves it

How a route carries which entry it answers for:

• ESP32 — the IDF gives each route a user_ctx, so begin() fills a static httpd_uri_t[] pointing into the table.
• RP2350 — ESPAsyncWebServer::on() takes a std::function, so the entry is captured instead.

Both loops are bounded by WebFrontend::MaxAssets, which a static_assert beside the table holds against the real count — adding a file without raising it fails the build rather than silently registering the first five of six.

What I deliberately did not do

Route dispatch and authorisation stay per backend. Their mechanisms genuinely differ (a C table of httpd_uri_t against .on() callbacks; a header decoded by hand against a library comparison), and moving them would have meant restructuring both 500-line web_test.cpp for little in return. The asset table is the part the simulator needs in stage D, and it is here.

The duplicated-blob risk, measured

This is the check the change turns on, since moving a header with internal linkage is exactly how you accidentally ship two copies of a 70 KB page:

	before	after
ESP32 flash	1 100 421	1 100 233
RP2350 flash	501 332	500 924

Flash went down on both. Nothing is stored twice, and the table costs less than the ten handlers did. The ESP32 gains 120 bytes of RAM for the static route array — five httpd_uri_t.

Verified

• AVR-Dx byte-identical: 48078 / 1700.
• All four targets build warning-free; both host suites pass.
• documented-sizes.py passes on all three targets (the ESP32's RAM moved 15.9 → 16.0 %, inside the point of slack the check allows).
• The panel renders in a browser: 19 of 111 cells lit, "ES IST VIERTEL VOR EINS", 12:45, brightness read back over the socket.

One honest note on that last check: it does not exercise the new table. serve.js answers the asset routes from disk itself, so what covers handleAsset is web_test.cpp on both backends — which does, and passes. The browser run covers the socket and JSON path.

A second honest note: the first browser run after starting the server came back with an empty plate, and two immediate re-runs were clean. The first page load is slower than the script's 3 s wait; the server log showed the socket connected and a frame delivered throughout. A flake in the check, not in the code.

Test change worth a look

The ESP32's stub had to learn that a route is a handler and a context. With one shared asset handler, capturing the function pointer alone made every asset answer as whichever registered last — the tests would have passed while testing one file five times.

🤖 Generated with Claude Code