Fix min/max form validation message to reflect inclusive boundary

[thswlsqls]

Fixes #27140

The number-field client validator registerMinMaxValidator() accepts the boundary values but its min-only and max-only error messages describe an exclusive range, misleading users about what is actually allowed.

Testing done

No JavaScript unit-test framework exists in the tree, so there is no automated test.

• Node reproduction of the branch logic: with min=5, value=5 is accepted while the old value=4 message read "should be larger than 5", implying 5 is invalid; the max-only branch (line 879) behaves the same. After the change the messages read "larger than or equal to" / "less than or equal to", matching the accepted range and the sibling min+max branch ("should be between …", line 843).
• yarn eslint and yarn prettier --check on the file pass.
• Only the two string literals change; the comparison logic is untouched, so runtime behavior is unchanged.

Screenshots (UI changes only)

Text-only change to an existing client-side validation message; no layout change.

• Before (min-only field, value below min): This value should be larger than N
• After: This value should be larger than or equal to N

The max-only branch changes analogously (less than → less than or equal to).

Proposed changelog entries

• Fix number field validation message to describe the inclusive min/max boundary

Proposed changelog category

/label bug, web-ui

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[MarkEWaite]

Causes test failures. Failing tests need to be fixed before the change is reviewed.

[thswlsqls]

@MarkEWaite Thanks for the review. You're right — NumberTest was still asserting the old wording in minValidation, maxValidation, and minAndMaxValidation; I've updated those assertions to match the new message. Pushed.

[thswlsqls]

@MarkEWaite CI is now green on the latest build — all four test jobs (JDK 21, JDK 25, Windows, and ATH) pass, so the test failures you flagged are resolved. Whenever you have time, could you take another look? No rush.