Add a real-browser test suite (Playwright/vitest browser mode), like slothlet's

[Shinrai]

Follow-up to #21. That work makes the package's reachable code path (UUID.TA/TB/IA, v1/v3/v4/v5/v6/v7/v8) browser-safe by removing static crypto/Buffer dependencies and swapping in isomorphic node/browser module pairs (./rng, ./bytes, ./hash) selected via the browser export condition.

All of that is currently verified only under Node, via unit tests that import the node-flavored modules directly and cross-check the hand-rolled browser MD5/SHA-1 against node:crypto's output for known vectors. That proves the logic is correct, but nothing currently proves the package actually loads and runs in a real browser with no Node globals present — a future change could reintroduce a stray Buffer/crypto/fs reference on the reachable path and the existing suite would stay green.

@cldmv/slothlet (/srv/repos/slothlet) has an established pattern for exactly this:

• .configs/vitest.browser.config.mjs + *.browser.test.mjs test files, run via @vitest/browser-playwright — real browser test execution, not jsdom.
• A standalone smoke script, tests/browser/playwright-smoke.mjs, run via npm run test:browser (pretest:browser runs npx playwright install chromium first) — builds/serves the package and loads it in a real headless Chromium instance.

Adopting the same shape here would mean:

• npm run test:browser (+ pretest:browser chromium install step) that loads @cldmv/uuid/main in headless Chromium with no Node polyfills, and exercises UUID.TA(), UUID.TB(), UUID.IA(), and v1/v3/v4/v5/v6/v7/v8, asserting they run without throwing and produce well-formed output.
• Where feasible, assert the browser output matches known values (e.g. v5(DNS, "www.example.com") against the standard RFC 4122 vector, and v3/v4 shape checks) so the browser path isn't just "didn't crash" but "produced correct UUIDs."
• Wire it into CI as its own job/check, separate from the existing Node vitest run, mirroring how slothlet keeps test:browser distinct from its main test/coverage scripts.

This isn't blocking #21's merge — the isomorphic module design and Node-side verification there are solid on their own — but it closes the gap between "verified correct" and "verified to actually run in a browser."