experiment: reconcile ambiguous Hermes request_promise 5xx

[kapunakap]

What

Prototype a non-replay recovery path for ambiguous Hermes request_promise HTTP 5xx responses.

Instead of replaying the POST, the provider performs one read-only GetProviderData check while the serialized Hermes queue entry is still active. It only treats the request as committed when provider identity, provider channel, chain, hashlock and fee all exactly match the request. Otherwise the original error continues through the existing failure counter.

The HTTP caller now preserves HTTP status for both recognized and unrecognized Hermes error bodies so generic 5xx can be distinguished from protocol-level errors.

Safety

• No automatic POST replay for generic 5xx.
• A mismatch, decode failure or reconciliation GET failure does not synthesize success.
• True sustained Hermes outages still hit the existing failure limit.
• This is stacked on fix: reset Hermes failure count after successful promise mysteriumnetwork/node#6219 because successful reconciliation must reset the consecutive-failure counter.

Open protocol question

Before proposing this upstream as production behavior, Hermes maintainers should confirm that data/provider/{providerID}.LatestPromise is sufficiently read-after-write consistent after an ambiguous request_promise 5xx, and that an exact latest provider-promise hashlock match is a valid commit witness.

Related: mysteriumnetwork#6218