Probe optional properties by column presence; add inverter diagnostics

[radzio]

The bug this starts from

The optional-feature probe decides support from the value a property returns:

temp_sensor = await self.GreeGetValues(["TemSen"])
if temp_sensor:
    self._has_temp_sensor = True

Plenty of supported properties legitimately read 0 — a compressor that is not
running, an unlocked child lock, a fault register with no fault. The probe runs
once and the result sticks, so whether a feature is detected depends on what the
unit happened to be doing when Home Assistant started.

This is observable across identical hardware: of four Gree units on one system,
AntiDirectBlow reads 2 on two of them and 0 on the other two. Only the
first two were detected, permanently.

The fix

Decide on whether the device echoes the column back. The firmware omits columns
it does not implement from a status reply, so the returned column list is the
supported subset — an unambiguous signal that does not depend on runtime state.

GreeGetValues threw that list away, so this splits the request out into
GreeFetchStatus and adds GreeGetSupportedValues next to it. Existing callers
are unchanged.

Probing is also what keeps polling safe, which is worth stating explicitly since
the new table makes it easy to add keys: SetAcOptions maps dat[i]
positionally onto the requested column list, so polling an unsupported key
shifts every value after it — and the shifted values are written straight back
to the unit by the next SendStateToAc.

Refactor

The five copy-pasted probe blocks (~85 lines) become a table in const.py and
one loop. All pending keys go out in a single request, since the reply
already classifies every one of them; a device that rejects the longer column
list falls back to per-key probes.

New entities

Properties this makes reachable, each gated on its own probe:

Platform	Properties
sensor	CompressorFqy, CompressorTem, InEvaTem, EnvTem, TemsSenOut, PM2P5, AllErr, JFErrorCode
binary_sensor (new platform)	Dfltr, ReplaceHEPA
switch	ChildLock, Dazzling, UvcControl, AutoClean, NobodySave

Writable ones are appended to the SendStateToAc command list; properties left
unset because the device lacks the feature are dropped by the existing filter.

CompressorFqy is documented as a system-level reading: on a multi-split every
indoor unit reports the shared outdoor unit's frequency, so it must not be
summed across units. Verified — all four units reported 26 Hz while only one had
Pow=1.

Secondary/duplicate sensors (EnvTem, TemsSenOut, PM2P5, JFErrorCode,
ReplaceHEPA) default to disabled to keep the entity list manageable.

A second commit swaps the deprecated CONCENTRATION_MICROGRAMS_PER_CUBIC_METER
for UnitOfDensity, with a fallback for older cores.

Testing

No test suite exists in the repo (per CLAUDE.md), so this was verified against
hardware: four Gree units, firmware V3.2.M, WiFi module V2.10, encryption v2.

• All 20 probed keys echo back in one request on every unit; debug log reports
  Optional properties not supported: none.
• All four units now detect AntiDirectBlow, including the two reading 0 that
  the old probe missed.
• 60 new entities created, values sane (compressor 49-51 °C, evaporator 26-27 °C,
  frequency tracking the outdoor unit).
• No errors in the HA log; check_config clean.

[p-monteiro]

The assumption of the device not returning values that it does not support is incorrect. The firmware will reply for things the physical unit does not support. Thus, using property probing to determine feature availability is impossible and a dead end. We either maintain a feature table based on device models and fw versions which is unfeasible for future maintenance, or we inquire the user for the features their devices actually support (the approach being used for the next version of the integration)