bbruntime: per-BlitzType release dispatch (re-enables testEmbeddedLists)

[CoreyRDean]

Summary

Closes the long-standing deferred finding: reference_map stored only a refcount, and _bbRelease(ptr, label) trusted the caller-supplied label for the destructor dispatch:

if (label == "BBCustom") _bbObjDelete(ptr as BBObj*);
else if (label == "BBList") _bbVectorFree(ptr);

_bbVectorRelease (fired when an element is removed from a BBList, or when an outer list iterates its elements during _bbVectorFree) hardcoded the label as "BBCustom" — it had no way to recover the element's static type once it lived as an int inside std::vector<int>. So:

• For BBObj-only lists (the common case) it worked.
• For lists holding inner BBLists, the outer free called _bbRelease(innerPtr, "BBCustom"). Refcount hit zero, dispatch ran _bbObjDelete on a std::vector<int>* — read+write into arbitrary heap. testEmbeddedLists was disabled because of this.

Change

• reference_map becomes map<int, RefSlot> where RefSlot { int count; const char *type; } — the type label is a const char* to a static literal (never copied, never freed).
• New _bbReferenceTyped(ptr, type) runtime helper for sites that know the static type at registration time.
• _bbNewVector stamps "BBList" at creation via _bbReferenceTyped.
• _bbRelease prefers the stamped type when present and falls back to the caller's label otherwise — BBObj entries that never went through _bbReferenceTyped keep working with the codegen's "BBCustom" label.

Test plan

• Re-enabled testEmbeddedLists in tests/ListTest.bb.
• Full BlitzForge test.bat suite passes (all 14 .bb test files).
• rcce2 test.bat (the consumer's server-module suite) passes against this build.
• CI build + macOS smoke.

🤖 Generated with Claude Code