Cache embedded Octicon data URIs across repeated registrations

[dexhunter]

Problem

In stateless HTTP use, a server and its tool inventory may be registered repeatedly. Each octicons.Icons call currently rereads two embedded PNGs and base64-encodes them through DataURI, even when the same icon was already registered earlier in the process.

On current main, registering all 31 required icons allocates a median 193,085 B/op and 527 allocs/op after warmup. A one-icon repeated registration allocates 4,160 B/op and 17 allocs/op.

Proposed change

Cache successful embedded (name, theme) data-URI reads on demand:

• preserve filesystem-based lookup for every embedded PNG, including names outside required_icons.txt;
• do not cache missing names or themes;
• keep returning a fresh []mcp.Icon from every Icons call;
• make concurrent first use race-safe;
• avoid reading or encoding all assets during package initialization.

Expected impact

The prototype changes warm registration as follows:

Inventory	Main	Prototype	Reduction
31 icons	193,085 B/op, 527 allocs/op	4,464 B/op, 31 allocs/op	97.69% bytes, 94.12% allocs
1 icon	4,160 B/op, 17 allocs/op	144 B/op, 1 alloc/op	96.54% bytes, 94.12% allocs

The first 31-icon registration increases from 240,464 B/op, 534 allocs/op to 247,080 B/op, 538 allocs/op while the cache is populated. If all current variants are used, it retains 46,840 bytes of immutable data-URI payload plus bounded map overhead; narrower inventories retain only requested variants.

The benchmark suite also checks fresh-process allocations, exact embedded-file behavior, custom themes, missing lookups, mutation isolation, and concurrent first use under the race detector.