get panstats: verb polish — error on invalid selector, list in banner, strict reset parsing

Follow-up from #3958 review

The get panstats [<panIndex>|<objectName>] [reset] bridge verb landed in #3958 and works correctly. Three low-severity polish items surfaced in review — none blocking, grouped here.

1. Silent empty result on an invalid selector (correctness / assertability)

get panstats 999 (out-of-range index) or get panstats NoSuchPan returns:

{"ok":true,"model":"panstats","pans":[]}

An automation driver can't distinguish "invalid selector" from "legitimately no panadapters" (e.g. a KiwiSDR session with no local pans). Other get verbs error on a bad selector — cf. get slice:

if (!s) return err("no slice for selector '" + selector + "'");

This is the Constitution Principle X (assertable/atomic state) concern: a driver should be able to tell what the bridge did and why. Fix: when a non-empty selector matches no SpectrumWidget, return err("no panadapter for selector '<selector>'") instead of {ok:true, pans:[]}.

2. panstats missing from the start() verb banner (discoverability)

src/core/AutomationServer.cpp start() logs the canonical verb list (ping, dumpTree, ... hover, showMenu, contextMenu, whoami, log, mark), but panstats (a get subverb, documented in docs/automation-bridge.md) isn't mentioned. An operator reading the banner wouldn't know it exists. Fix: add panstats (or note the get subverbs) in the banner.

3. Lenient reset parsing (strictness)

get panstats 0 reset resets correctly, but get panstats 0 <typo> silently treats any unrecognized property as "don't reset" rather than erroring — so a driver can't catch a mistyped reset. Fix: if the property token is non-empty and not reset, return an error.

Acceptance

• get panstats 999 / bad objectName → {"ok":false,...} with a clear reason.
• Startup banner lists panstats.
• get panstats 0 rest (typo) → error, not a silent no-reset.

Filed as the consolidated follow-up noted in the #3958 review. All three are polish; the verb's counters/threading/measurements are correct as-is.

Start with the get panstats implementation and start() in src/core/AutomationServer.cpp; compare invalid-selector handling with the get slice example in the issue. Check docs/automation-bridge.md for the documented verb, then verify the three acceptance cases: bad selectors and unknown reset properties error, and the startup banner lists panstats.