flamegraph: intern module paths, and say what width means on a GPU page (#123)

[dpsoft]

Two items from the flame-graph UI research, both self-contained.

1. Modules declared once per page

data-module carried the full path on every frame: 566,966 bytes of a 3,165,745-byte page (18%)
for thirteen distinct values totalling about a kilobyte.

The renderer already applies the opposite rule two lines above the emit site, and says so:

No inline colour: data-domain below selects fill, hatch and outline from paletteCSS, so a
domain's colour is declared once for the whole page rather than once per frame.

Modules are the field that missed it. They are now a JSON table at the top of the chart, with each
frame carrying data-m, an index into it.

page	before	after
AFTER-cpu-python-walker	3,237,071	2,728,530 (−15%)
GPU-mnist-pytorch	1,129,657	1,002,794 (−11%)

Emitted only when a profile has modules, so a GPU profile — which the builder writes with empty
mappings — pays nothing. Sorted, so the same profile renders byte-identical.

Not HTML-escaped, which is the subtle part: HTML entities are not decoded inside a <script>
element, so escaping would hand JSON.parse a document full of ". json.Marshal already
writes <, >, & as < etc., which makes </script> unrepresentable — asserted with a
module path that tries to break out.

2. A GPU page says what a frame's width measures (#123)

Under [gpu:launch] a CPU frame is as wide as the device time launched from that call path,
not the CPU time spent in the frame. A reader fluent in flame graphs assumes the opposite, because
that is what the shape means everywhere else, and the page carried no signal to correct them. It
was documented only in prose on an index page most viewers never open.

The tooltip now says so, per band — kernel, boundary, unattributed, and everything else — and
only on a GPU profile, decided from the axis label. On a CPU profile the width is the obvious
thing and a caption on every frame would be noise.

Please review this one properly

I introduced three bugs on this branch and caught each only after writing the code:

1. Interning broke the tooltip's module line. I claimed "nothing reads data-module" — the
   page's own detail() reads it as d.module through a dataset alias my grep missed. There is
   now a test asserting the page ships a reader for the table, not just the table.
2. A nine-line prose comment went into the shipped script, which
   TestTheShippedAssetsCarryNoProseComments exists to prevent — every comment there is bytes sent
   to every reader. Moved to the Go declaration.
3. Removing that comment deleted the function widthMeaning(it,d){ line with it, leaving a
   bare function body — and the entire Go suite still passed, because nothing here parses
   JavaScript. A broken script would have shipped and failed only in a browser. There is now a
   structural check on the asset: brace/paren balance, and the presence of every function the
   tooltip path calls.

The third is the one worth a second opinion: the guard I added catches the damage a text edit to a
template literal does, but it is not a parser, and this branch is evidence that the JS in this
repo has no real safety net.