Add Mitsubishi WF-RAC integration

[blues-sechseck]

Proposed change

New integration for Mitsubishi Heavy Industries air conditioners fitted with the WF-RAC wireless LAN module (sold under that part number, marketed together with the Smart M-Air app). It talks to the module over the local network using the same HTTP API the app uses — no manufacturer account, no outbound connection, local_polling.

Cut back after the first review. @joostlek asked for a smaller first PR with diagnostics and the reconfigure flow split off, and this is that PR. Diagnostics, the reconfigure step and the options dialog are gone; quality_scale is bronze. What is left is the integration proper: the climate platform, the coordinator, a config flow with manual, discovery and zeroconf steps, and the migration chain. The removed pieces come back as their own PRs, along with the seven further platforms the custom component has.

Four things worth flagging before review:

• The protocol layer is a separate library. pywfrac holds everything that builds and parses the module's airconStat frames. It takes an injected aiohttp session and an explicit certificate path rather than reaching into hass, is fully typed, and has its own test suite. Pinned at 0.1.3; this PR moves it up from 0.1.0 (diff). The three steps redact the operator and device ids from debug logs, refuse a fan value the protocol cannot encode instead of silently sending an empty nibble, and name the field when they do.
• The domain is mitsubishi_wf_rac, next to the existing melcloud. Those are two different manufacturers: melcloud is Mitsubishi Electric, this is Mitsubishi Heavy Industries, with an unrelated protocol and no shared hardware.
• async_migrate_entry and VERSION = 7 are included even though core has no old entries of its own. The domain matches the custom component's, so an installation that switches over carries config entries of versions 1–6 with it, and those would fail to load without the migration. The last two steps are v5 → v6, which moves the host from options back into data where the discovery helper that refreshes a changed address actually writes it, and v6 → v7, which registers the airco id as the entry's unique id so a moved unit is recognised rather than offered as a new discovery.
• The module presents a self-signed certificate. If ac_cert.pem is present in the configuration directory the integration pins it; without it the connection falls back to a permissive SSL context. const.py carries the filename and the openssl recipe that produces it.

On which models this covers: the WF-RAC module is the common part, not the indoor unit. It is an accessory fitted to Mitsubishi Heavy Industries split systems, and the protocol is the module's rather than any one model's — the capability flags in the frame say what the unit behind it can do, so ceiling cassettes and wall units answer the same interface with different capabilities. The documentation page names the models this has been confirmed on.

Verified locally: python3 -m script.hassfest (all 1,515 integrations, 0 invalid), python3 -m script.gen_requirements_all validate (no diff), ruff check and ruff format, mypy, pylint, and pytest tests/components/mitsubishi_wf_rac — 100 tests, 100 % coverage in every module.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• 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:
• Link to documentation pull request: Add Mitsubishi WF-RAC integration documentation home-assistant.io#47923
• Link to developer documentation pull request:
• Link to frontend pull request:
• Link to brands pull request: Move mitsubishi_wf_rac to core integrations brands#11109

Checklist

• I understand the code I am submitting and can explain how it works.
• 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
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.