fix: normalize generated viewport dimensions

[Shlummie]

Fixes #6.

Summary

Fixes generated fingerprints that expose zero viewport dimensions such as innerWidth, innerHeight, clientWidth, and clientHeight.

Why

Issue #6 reports Chrome/macOS fingerprints where those viewport-related fields are 0 while the surrounding screen fields are populated. That creates an internally inconsistent fingerprint and can be flagged by services such as Pixelscan.

Changes

• Normalize generated screen fingerprints before returning them from FingerprintGenerator.
• Preserve existing non-zero values, but fill missing or zero viewport/client dimensions from coherent outer-window dimensions.
• Use innerWidth and innerHeight as the Playwright/Puppeteer viewport dimensions while keeping screen.width and screen.height as physical screen dimensions.
• Add regression coverage for non-zero coherent desktop Chrome viewport dimensions.

Verification

• cmd /c node_modules\.bin\vitest.CMD run test\fingerprint-generator\generation.test.ts
• cmd /c node_modules\.bin\tsc.CMD --noEmit -p tsconfig.json
• cmd /c node_modules\.bin\prettier.CMD --check packages\fingerprint-generator\src\fingerprint-generator.ts packages\fingerprint-injector\src\fingerprint-injector.ts test\fingerprint-generator\generation.test.ts

Note: cmd /c node_modules\.bin\tsc.CMD --noEmit -p test\tsconfig.json currently fails on pre-existing header-generator test type issues unrelated to this patch.

[barjin]

Thank you, @Shlummie, for the diagnosis! I believe the fix is at the wrong layer, though.

The training pipeline already validates every record with a zod schema at packages/generator-networks-creator/src/record-schema.ts (used in generator-networks-creator.ts:32). The screen-related fields are defined as z.number().nonnegative(). That permits 0, which is exactly what's leaking into the model and out into your fingerprints.

Fixing those schema rules kills the bug at the source. Records with zero viewport dims get rejected at training, the network never learns to emit them, no runtime normalizer needed.

If you decide to keep the runtime check nonetheless, it imo should warn/throw on violations rather than silently rewrite.

Happy to re-review once it's restructured.

[barjin]

Closing in favour of subsequent PRs.