Nexent traditional Python unit tests

Paths below are relative to the repository root.

These tests are a permanently maintained suite kept separate from the requirement-driven D1-D5 system. Historical documents may call it Legacy UT; that does not mean planned removal. Do not assign formal D1-D5 Case IDs to UT, bind it under test-e2e/cases/, or count it in the generated functional baseline. Use nexent-test-assets for formal Cases.

Isolated validation, arithmetic, local branches and error conversion belong primarily here, including when adding tests after code is already developed. Read existing inputs/assertions before adding another test; reuse adequate coverage or strengthen missing variants in its owning suite. Do not copy/wrap UT as formal D1 solely for a Feature link, Case count or report entry. New formal D1 requires distinct component-contract evidence with real internal collaboration through nexent-test-assets; an API/runtime boundary may legitimately verify the same rule again. Preserve existing D1 rather than bulk deleting or relabeling overlaps. For formal test backfill, use nexent-test-assets' test-backfill mode; UT results remain separate.

For every product-code change, assess applicable unit behavior and document reuse, strengthen, add or a justified non-behavior exemption. New or changed behavior requires success, boundary and error coverage. Bugfixes require a regression assertion that detects the defect; demonstrate failure before the fix where feasible. Existing adequate coverage may be reused without artificial file edits. Derive expected behavior from requirements/contracts, not merely the implementation. Relevant local UT verification is mandatory before a product-code PR; CI independently runs its configured UT set. Failures, collection errors and unavailable execution are not passes. UT does not replace required component/API/runtime/journey/risk acceptance.