docs(ac-filter-reset): record a board family with no local reset (ARTIK051_PRAC_20K)

[creednmd]

Docs only — no code touched.

docs/investigations/ac-filter-reset.md is written around the FilterTime_<N> option token on /mode/vs/0, and its "solved" conclusion holds for the ARTIK051_KRAC_18K it was measured on. On an ARTIK051_PRAC_20K (three-head multi-split, v0.21.0, HA 2026.8.1) that token does not exist — no FilterTime, no FilterAlarmTime, no FilterCleanAlarm anywhere in the options blob. The counter lives in /filter/airdustfilter/vs/0 as a percentage of a 500-hour interval instead, and nothing resets it locally.

Three attempts, all against a live unit put in fan_only first (writes to a powered-off head on this board are dropped silently, which would otherwise look identical to a rejection):

Target	Payload	Result
/mode/vs/0	{"x.com.samsung.da.options": ["FilterCleanAlarm_Clear"]}	4.00, options blob byte-identical
/filter/airdustfilter/vs/0	{"x.com.samsung.da.filterUsage": "0"}	4.00
/filter/airdustfilter/vs/0	{"x.com.samsung.da.filterUsage": 0} (integer)	5.00

filterUsage stayed at 96 throughout, verified by a live re-read after each write rather than by the integration's optimistic state.

The last two rows are the informative pair: they differ only in JSON type and return different codes. An unresolved href or an unrecognised field name would fail identically, so the board is parsing the field, faulting on the wrong type, and still refusing the value when correctly typed. Read-only, not mis-addressed.

Also flags one trap in passing: filterResetType: ["replaceable","washable"] describes the filter, not an available reset command, though it reads like a hint that one exists.

The patch adds a scope line to the intro pointing at the new section, and appends the section itself with both resource dumps, the attempt table, the reasoning, and an observation-only workaround (numeric_state below: 10 on the usage sensor stamping an input_datetime) for boards in this family.

Happy to reword or trim if you would rather keep the file strictly about the KRAC generation — the goal is just that the next person with a percentage-counter board does not repeat the three writes.