fix: guard customElements.define against double-registration

[dmchaledev]

Problem

The element is registered unconditionally at the bottom of the module:

customElements.define('hailbytes-vuln-calculator', HailbytesVulnCalculator);

CustomElementRegistry.define() throws a DOMException if the name is already
registered. So if this module is evaluated more than once on the same page,
the second evaluation throws an uncaught error that aborts the rest of that
script and can break the host page.

This is a realistic scenario for a distributable web component:

• A site loads the component from a CDN <script type="module"> and also
  pulls in a bundled copy via a framework dependency.
• Two independently-bundled widgets on the same page each include the component.
• A CDN URL is referenced both pinned and via @main/@latest, resolving to
  two module instances.

The failure mode is silent in dev (one copy) and only surfaces in the field,
which makes it especially worth guarding at the source.

Fix

Register only when the name isn't already taken — the standard defensive
pattern for shippable custom elements:

if (!customElements.get('hailbytes-vuln-calculator')) {
  customElements.define('hailbytes-vuln-calculator', HailbytesVulnCalculator);
}

Test

Adds test/define-guard.test.mjs, which installs a customElements shim that
throws on duplicate define() (mirroring browser behavior) and then imports the
module twice (using a query-string suffix to force a second ESM evaluation). The
test fails against the old unguarded code and passes with the guard.

Verified locally:

• Without the fix: # pass 0 / # fail 1
• With the fix: full suite # tests 66 / # pass 66 / # fail 0

Scope

Single-file behavior change plus one test and a CHANGELOG entry. No public API,
output shape, or calculation change.

🤖 Generated with Claude Code

---

Generated by Claude Code