Expose options from simple alternation match() schemas in UI schema

[kingpanther13]

Proposed change

Schema elements of type match() are rendered in the UI as plain string fields
with no suggestions, even when the regex is a simple alternation of literal
values. The Samba add-on's enabled_shares
(match(^(?i:(addons|addon_configs|backup|config|media|share|ssl))$)) is the
visible case: the configuration UI shows a multi-value field with an empty
suggestion list (home-assistant/frontend#51510).

This extracts literal options from match() patterns that are fully anchored
alternations of plain literals and includes them as options on the UI schema
node. Extraction is strictly conservative: the pattern must be anchored with
^...$, and any regex metacharacter, escape, class, quantifier, or nested
group falls back to current behavior. Options are deduplicated preserving
order, and the added tests assert that the emitted options are exactly the
values the pattern accepts (case-insensitively for (?i) patterns), so
suggestions can never produce a value that fails validation.

Validation (AppOptions) is unchanged: fields still validate against the
original regex, so values that only match case-insensitively remain accepted.
Add-on schemas cannot simply switch such fields to list() without breaking
existing configs, since list() validates case-sensitively.

Surveyed all match() patterns across the official add-ons repository and the
largest community repositories (hassio-addons, alexbelgium): 20 of 22 distinct
patterns are unchanged; 2 gain options, both verified to be exactly the
accepted value set.

The frontend counterpart that consumes options on multi-value string nodes:
home-assistant/frontend#53077. Older frontends ignore the additional key.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Addon config multi-select chip inputs show an empty suggestion list frontend#51510
• Link to documentation pull request: N/A (the UI schema node format is not
  documented in developers.home-assistant.io; authoring syntax is unchanged)
• Link to cli pull request: N/A (the CLI does not process the schema field)
• Link to client library pull request: N/A (aiohasupervisor types schema nodes
  as dict[str, Any]; the additive key needs no model change)

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io
• CLI updated (if necessary)
• Client library updated (if necessary)

[home-assistant]

Hi @kingpanther13

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[agners]

2 gain options, both verified to be exactly the
accepted value set.

This seems a rather small group. I think I'd prefer if we release a Samba app which forces the option to be lower case, then do a second release later where we switch from match() to list(). That seems rather straight forward and chances that someone won't update to that intermediate version and uses non-lower case option is rather small. And even if so, the error will make it clear what needs to be changed.

[kingpanther13]

I originally was going to do a PR on Samba, but I went this direction because I was afraid that the change would silently break people's configs. If you feel that this isn't the right way to go I'll happily file a new PR against Samba instead.

[agners]

I originally was going to do a PR on Samba, but I went this direction because I was afraid that the change would silently break people's configs. If you feel that this isn't the right way to go I'll happily file a new PR against Samba instead.

Yes, let's change the Samba config. The first step won't be a breaking change. The second step we can bundle with other changes like the new Netbios config default, and mark it clearly as a breaking change.