fix: prevent field label leak through rule parameters in validation messages

[gr8man]

Description

Validation::getErrorMessage() used the rule parameter as a key into the
defined field rules to substitute the referenced field's label in the error
message. When a parameter that was not a field reference (e.g. a numeric
limit like min_length[secret]) coincidentally matched a defined field
name, that field's label leaked into the error message (information
disclosure of internal field labels plus a wrong message).

Label substitution now only applies to rules whose parameter is a field
reference: matches, differs, required_with, required_without. Other
rules render the parameter verbatim.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

We should also add uploaded and is_image here.

[michalsn]

Sadly, I now see that this introduces a compatibility issue with custom rules.
For example, an application could define a rule that references another field:

example_rule[password]

If password has the label Your Password, a custom error message such as:

'example_rule' => 'The {field} field must match {param}.'

would now return:

The Confirmation field must match password.

instead of:

The Confirmation field must match Your Password.

The validation result would remain unchanged, but existing error messages would change because custom rules cannot appear in the hardcoded list.

The underlying issue is that we cannot reliably determine whether a parameter is a literal value or a field reference without knowing the rule semantics. Given this compatibility tradeoff, I think we should leave the current behavior unchanged for now.