IBX-11959: Exposed configured password requirements to the frontend

[tbialcz]

🎫 Issue	IBX-11959

Related PRs:

• Requires IBX-11959: Added getters to Translation Message and Plural value objects core#795

Description:

Backend part of showing password requirements on the "Set new password" screen:

• ibexa_password_requirements() Twig function returning the list of rules enabled in the user content type's PasswordValueValidator config (PasswordRequirementsResolver),
• password constraint violations now carry code = requirement identifier, so the frontend can mark which rules were not met after submit,
• PasswordResetController passes content_type to the view (the user on the reset screen is not logged in).

Validation logic itself is unchanged.

For frontend:

{# reset password page — content_type comes from the view #}
{% for requirement in ibexa_password_requirements(content_type) %}
    <li data-requirement="{{ requirement.identifier }}">
        {{ requirement.translationKey|trans(requirement.parameters, 'ibexa_password_requirements') }}
    </li>
{% endfor %}

{# pages with a logged-in user — no argument needed #}
{% for requirement in ibexa_password_requirements() %}

After submit, failed rules are in form.new_password.first.vars.errors — match error.cause.code against requirement.identifier.

For QA:

Full scenario (requirements list on the page) is testable once the storefront PR consuming this API is up. On this PR alone:

1. Reset password page: submit a password violating several rules (e.g. abc) — one error per unmet rule is displayed, password is not changed.
2. Submit a valid password — reset works as before.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[konradoboza]

Aren't those configurable and should be dynamically incorporated? How about dynamic labels generation for custom ones?

[ViniTou]

it seems they are dynamically added based on actual constraints value?

[tbialcz]

the values come from the config, and only the list of rules is fixed, just like in the core schema. After the Slack discussion, I simplified it to a single rules table, and the labels and translations are generated from that table.

[konradoboza]

Should this be even static?

[tbialcz]

it is a const . The map never changes at runtime, so const is the right i think,static would allow mutation for no reason.