plan: claim the stb_vorbis heap overflow (#security, OPEN since 2026-08-18)

Root cause found before claiming, so the claim is not a placeholder:
setup_malloc takes an int, so sizeof(char*) * comment_list_length truncates
13,174,835,200 -> 289,933,312 (exactly ASAN's allocation size) while the
memset computes the same product in size_t and writes the full 13 GB (exactly
ASAN's write size). The allocation truncates; the consumer does not.

Upstream nothings/stb master still carries both the int-typed setup_malloc and
the truncating multiply, so there is no upstream fix to pull — which is what
the OPEN item asked to check first.