fix!: isolate DSL class tags across addons

[GrapeBaBa]

Summary

• derive DSL class napi_type_tag values from stable content identities instead of process-local addresses
• require an addon-unique .type_tag salt in js.exportModule and allow per-class overrides in js.class
• add a second addon fixture proving identically named mod.Counter classes cannot cross the native pointer boundary

Problem

DSL class tags were derived only from @typeName(T). Separate addons conventionally rooted at mod.zig can both contain mod.Counter, producing the same tag. An exported function accepting *Counter could then accept an object from the other addon, pass napi_check_object_type_tag, and reinterpret unrelated native memory as its own class.

An address-based tag isolates simultaneously loaded addons but changes after unload/reload, which does not satisfy Node-API's stable type-tag contract.

Approach

This follows napi-rs' content-identity approach from napi-rs#3405:

• hash {salt}::{@typeName(T)} with 128-bit FNV-1a
• split the hash into napi_type_tag.lower and .upper
• lock the algorithm with the same known vector
• let js.class(.{ .type_tag = "..." }) replace the module salt for one class

Zig does not expose Cargo-like package name/version metadata to imported source modules, so zapi requires the addon identity explicitly:

comptime {
    js.exportModule(@This(), .{
        .type_tag = "6f9619ff-8b86-d011-b42d-00cf4fc964ff",
    });
}

The salt should be generated once and kept stable. A UUID is recommended.

Breaking change

DSL addons using js.exportModule must add .type_tag. Low-level napi.module.register users are unchanged.

Testing

• pnpm build
• pnpm test — 117 tests passed
• zig build test:zapi -Doptimize=ReleaseSafe
• zig fmt --check ...
• pnpm lint:js
• Bun 1.3.11 cross-addon rejection smoke test
• duplicate-load smoke test confirms two loaded copies of the same addon retain the same class identity