fix(mtconnect): an Agent refusal of /current is a reply, not a comms fault

Health contract: an MTConnectError document (NO_DEVICE, INVALID_REQUEST, ...) is the
Agent answering. The parsers now mark such an InvalidDataException
(MTConnectXml.IsAgentRefusal - the type is sealed, so a Data marker, every other
handler unchanged); ReadAsync reports the batch Bad but does not degrade the read
path, advances LastSuccessfulRead, clears a prior read degradation and warns once
per distinct refusal. An unparseable answer stays a comms fault.

Refs #743

Claude-Session: https://claude.ai/code/session_01Ub9hGmYLQvn9XETzw7CMsT

docs/drivers/MTConnect.md

@@ -123,6 +123,13 @@ read-path degradation an earlier failed `/current` left (the read path is answer
 checks the answer's `instanceId`: a changed one (an Agent restart seen by a browse-only driver with no pump) drops the
 cached `/probe` model and raises `OnRediscoveryNeeded` once per distinct id — it used to be detected only by the pump.
 
+**An Agent refusal is a reply (health contract).** An `MTConnectError` document answering `/current` (e.g.
+`NO_DEVICE` for a wrong `DeviceName` scope) still fails the batch (`BadCommunicationError` per ref), but it is the
+Agent answering, not a comms fault: the read path is not degraded by it (that would let the comms-loss watchdog
+reconnect-loop the driver over a configuration problem), `LastSuccessfulRead` advances, a prior read degradation
+clears, and the Agent's text is logged once per distinct refusal. An answer that is not an MTConnect document at all
+(a proxy's HTML page, truncated XML) stays a comms fault.
+
 ## Minimum deployment
 
 ```jsonc