feat: Add description support for PropertyFilter free text operators

[ernst-dev]

Description

Let consumers control the operator used for free-text filtering in PropertyFilter, and expose it for custom handling.

The base freeTextFiltering API (operators, defaultOperator) already lets consumers pick which operators are available for free text and which is the default (for example contains vs equals vs starts-with). However, free-text operators could not carry a consumer-provided description the way property operators can (PropertyFilterProps.FilteringProperty operators accept description). As a result:

• Custom free-text operator strings (for example ~) showed an empty description in the operator dropdown.
• Consumers could not override the built-in description of a predefined free-text operator.
• The token editor worked around this with a fragile heuristic that searched all filtering properties for one that happened to define a custom description for the same operator, then reused it for free text.

This PR adds an opt-in description field to the free-text extended operator object and wires it through the token editor operator dropdown, mirroring the existing property-operator description pattern.

What changed

• PropertyFilterTextOperatorExtended now accepts an optional description string.
• InternalFreeTextFiltering gains a getOperatorDescription(operator) resolver, built from the extended free-text operators in internal.tsx (same pattern as InternalFilteringProperty.getOperatorDescription).
• OperatorInput (token editor) prefers the explicit free-text description, then falls back to the previous property-reuse heuristic, then to the built-in i18n string — so existing behavior is preserved.

Backward compatibility: fully backward compatible — description is a new optional field; when omitted, the built-in i18n descriptions are used exactly as before.

Related links, issue #: SIM AWSUI-61808.

⚠️ Ticket mismatch note: SIM/Taskei AWSUI-61808 currently resolves to "More flexible board components" (Core / Roadmap), which is unrelated to the PropertyFilter free-text operator work described in the task. This PR was implemented per the provided task description (free-text operator control / custom handling) rather than the board-components ticket content. Flagging so the ticket link can be corrected.

How has this been tested?

• Unit tests (src/property-filter/__tests__/property-filter-token-editor.test.tsx):
  • uses custom descriptions provided for free text operators — verifies the free-text operator dropdown (and token trigger) shows consumer-provided descriptions, including for a custom ~ operator with no built-in i18n fallback.
  • falls back to the built-in description when no custom free text description is provided — verifies mixed operators (custom description + built-in) resolve correctly.
• Full src/property-filter unit suite: 349 passed / 17 suites.
• quick-build (TypeScript + styles): green.
• eslint on all changed files: no errors.
• Dev page for manual/visual testing: pages/property-filter/property-filter-freetext-operator.page.tsx demonstrates defaultOperator: '=', custom descriptions on =/:/^, and a custom ~ free-text operator with a match function and description.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates. — JSDoc updated for freeTextFiltering.operators and the new description field.
• Changes are backward-compatible if not indicated. — Yes, new optional field only.
• Changes do not include unsupported browser features. — Yes.
• Changes were manually tested for accessibility. — Operator descriptions surface in the existing Select control; token trigger text updated accordingly.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function. — N/A (no URL handling).

Testing

• Changes are covered with new/existing unit tests? — Yes (2 new unit tests + existing suite).
• Changes are covered with new/existing integration tests? — Existing integration tests unaffected; a dev page is provided for manual verification.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.61%. Comparing base (f97729a) to head (1a1aabf).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4816   +/-   ##
=======================================
  Coverage   97.61%   97.61%           
=======================================
  Files         952      952           
  Lines       30816    30822    +6     
  Branches    11318    11320    +2     
=======================================
+ Hits        30081    30087    +6     
- Misses        688      728   +40     
+ Partials       47        7   -40     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.