Make reconnect/grace timing self-documenting (grace vs downtime is currently hidden in step code)

Reconnect/grace scenarios depend on the provider's retryGracePeriod relative to the connection is lost for Ns downtime, but that grace value lives in each provider's step definitions (not the gherkin). So a reader sees e.g. lost for 8s -> expect error with no visible grace, and it's only correct because the step code happens to set grace below 8. This is confusing and couples downtimes to a hidden value.

Idea: make grace explicit in the feature via the existing an option "retryGracePeriod" ... step so the grace-vs-downtime relationship is self-documenting.

Caveat that stopped us from doing it now: it's inconsistent to surface only retryGracePeriod in the gherkin while retryBackoffMs, retryBackoffMaxMs, deadlineMs, keepAliveTime, etc. remain in step code. A proper fix should decide, consistently, which timing knobs belong in the feature vs. the harness (and requires every provider to stop overriding whatever moves into the gherkin).