Fix: message_length_limit config is ignored when CLI flag is unset (commit/check)

[ttw225]

Description

When message_length_limit is configured (e.g., in pyproject.toml), cz commit / cz check should enforce it unless the user explicitly overrides it via the CLI -l/--message-length-limit.
Currently, if the CLI argument exists but is None/unset, the code path ends up treating it as “no limit”, so the configured limit is not applied.

Reason why:

1. argparse leaves message_length_limit as None when the flag isn’t provided (no default is set). eg. cz commit
2. Because the key still exists in arguments, arguments.get("message_length_limit", ...) returns None and never falls back to config.settings, effectively bypassing the configured limit.

Steps to reproduce

1. Create a pyproject.toml with:

[tool.commitizen]
name = "cz_conventional_commits"
message_length_limit = 10

2. Run either:

• cz check --message "feat: this is definitely too long"
• or cz commit --dry-run and enter a subject that makes the first line longer than 10 characters.

3. Ensure you did not pass -l/--message-length-limit.

Current behavior

The configured message_length_limit from pyproject.toml is not enforced when the CLI flag is unset, allowing too-long subjects to pass.

Desired behavior

• Enforce message_length_limit from config when -l/--message-length-limit is not provided.
• Precedence should be CLI > config > default (0 = no limit).
• -l 0 should explicitly disable the limit even if config sets one.

Screenshots

Environment

Commitizen Version: 4.13.9
Python Version: 3.14.3 (main, Feb 3 2026, 15:32:20) [Clang 15.0.0 (clang-1500.1.0.2.5)]
Operating System: Darwin