feat: enforce minimum password length of 8 characters with warning

[jlima8900]

Summary

• Enforce minimum password length of 8 characters in the $GEN local record-field helper
• $GEN:rand,<8> now clamps to 8 with a logging.warning instead of silently accepting values as low as 4
• Default rand, dice, and crypto algorithms unchanged

Contract change

generate_password() no longer honors explicit $GEN:rand,<N> requests where N < 8. Values below 8 are forced to 8 with a warning. This is intentional policy to prevent weak passwords from being generated through the CLI helper.

This applies only to the local $GEN helper in record_edit.py — enterprise password complexity rules and separate workflow-specific paths are unaffected.

Test plan

• $GEN:rand,4 → clamps to 8, emits warning
• $GEN:rand,6 → clamps to 8, emits warning
• $GEN:rand,8 → produces 8 chars, no warning
• $GEN:rand,24 → produces 24 chars
• $GEN (no params) → default 20 chars
• $GEN:rand (no length) → default 20 chars
• $GEN:dice,5 → unchanged behavior
• $GEN:crypto → unchanged behavior
• 9 unit tests in unit-tests/test_password_generator.py, all passing

[jlima8900]

Note on enterprise password policy:

generate_password() does not consult the enterprise enforcement policy (PasswordRule / DomainPasswordRulesRequest). An enterprise admin can enforce minimum 16 characters with symbols, but $GEN:rand,4 would produce a 4-character password with no validation against that policy.

This PR raises the hardcoded floor from 4 to 8 as a safety net, but the deeper fix would be for generate_password() to check the enterprise password rules when available and use those as the minimum instead of a static value.

That's a larger change (requires params access in generate_password(), API call to fetch rules) — noting it here as a follow-up consideration.

[aaunario-keeper]

don't submit PRs against master, do it against release branch instead
also, are we sure 4 isn't an expected minimum (are we sure that admins don't have the ability to set it to that currently?)
ideally we'd want to fix this properly and avoid relying on half-measures as you pointed out, have you made the corresponding JIRA ticket?

[aaunario-keeper]

following up after a repo-local pass: i don't think the enterprise password-rule concern is the blocker here. $GEN in record_edit.py is a local record-field helper, and commander already has separate complexity-driven paths for workflows that actually consume explicit password complexity.

the concrete gap in this PR is test coverage. this should add targeted unit tests for the new clamp/warning behavior in generate_password():

• $GEN:rand,4/6 clamps to 8 and warns
• $GEN:rand,8 does not warn
• default rand, dice, and crypto behavior remains unchanged

the other thing i'd like called out explicitly before merge is the contract change: this no longer honors an explicit $GEN:rand,<8> request and will force 8 instead. if that is intentional policy for this helper, say so in the PR/ticket and add the tests above.

[jlima8900]

Thanks for the detailed follow-up. Addressing both points:

Target branch: Understood — I'll retarget this PR to the release branch.

Contract change + test coverage: You're right that this is an intentional policy change — $GEN:rand,<8> will now clamp to 8 with a warning rather than honoring the lower value. I'll call that out explicitly in the PR description and add the requested unit tests:

• $GEN:rand,4 and $GEN:rand,6 clamp to 8 with warning
• $GEN:rand,8 passes through without warning
• Default rand, dice, and crypto behavior unchanged

Agreed that the enterprise password-rule concern is a separate issue — this PR is scoped to the local generate_password() floor only.