Stabilize scalar DVS normal-flow normalization

[FlorianPfaff]

Bug

pyrecest.experimental.dvs.signed_normal_flow() normalized contour normals and velocities with numpy.linalg.norm. For large but finite vectors such as [1e308, 1e308], the internal sum of squares overflows even though the true Euclidean norm remains representable.

For a horizontal normal and a 45-degree velocity at that scale, the helper returned 0.0 instead of sqrt(0.5). With NumPy overflow handling configured to raise, it raised FloatingPointError. The profile and activity helpers inherit the same failure because they call this scalar path.

The vectorized DVS tracker path already uses scale-safe velocity normalization, but the public scalar active-contour helpers remained vulnerable.

Fix

• compute Euclidean norms with a scale-safe numpy.hypot.reduce helper;
• normalize both the normal and velocity before taking their dot product, keeping the final arithmetic bounded;
• preserve the existing zero-vector behavior;
• add focused scalar and profile regressions using extreme finite normals and velocity.

Validation

• reproduced the pre-fix result: 0.0 instead of 0.7071067811865475;
• reproduced the pre-fix FloatingPointError under numpy.errstate(over="raise", invalid="raise");
• verified the patched scalar/profile calculation returns [sqrt(0.5), sqrt(0.5), -sqrt(0.5)] without overflow;
• branch is 2 commits ahead and 0 behind main;
• final diff is limited to the active-contour helper and its focused test module.

GitHub Actions should provide the full supported Python, backend, lint, packaging, documentation, and security validation matrix.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	25.84s
✅ JSON	prettier	7	0	0	0	1.14s
✅ JSON	v8r	7		0	0	4.73s
✅ MARKDOWN	markdownlint	68	0	0	0	1.71s
✅ MARKDOWN	markdown-table-formatter	68	0	0	0	0.62s
✅ PYTHON	black	1809	56	0	0	93.57s
✅ PYTHON	isort	1809	88	0	0	2.74s
✅ REPOSITORY	betterleaks	yes		no	no	2.54s
✅ REPOSITORY	checkov	yes		no	no	54.09s
✅ REPOSITORY	gitleaks	yes		no	no	16.75s
✅ REPOSITORY	git_diff	yes		no	no	0.33s
✅ REPOSITORY	secretlint	yes		no	no	80.31s
✅ REPOSITORY	syft	yes		no	no	5.63s
✅ REPOSITORY	trivy-sbom	yes		no	no	7.12s
✅ REPOSITORY	trufflehog	yes		no	no	33.45s
✅ YAML	prettier	11	0	0	0	0.79s
✅ YAML	v8r	11		0	0	12.46s
✅ YAML	yamllint	11		0	0	0.62s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@9.6.0 --custom-flavor-setup --custom-flavor-linters PYTHON_BLACK,PYTHON_ISORT,COPYPASTE_JSCPD,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_GITLEAKS,REPOSITORY_BETTERLEAKS,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY_SBOM,REPOSITORY_TRUFFLEHOG,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository

[FlorianPfaff]

Closing as low value. The change is dedicated to normalization at near-maximum floating-point magnitudes (around 1e308), where the downstream geometry is not a meaningful supported operating regime. The added special-case path would increase maintenance complexity without practical benefit.