Refactor Gherkin step to clarify fatal state verification (step naming: event vs state, SDK vs implementation)

[aepfli]

A new Gherkin step And the client is in fatal state was recently added. In other tests, we use a pattern of correlating the step directly with the object or event being checked, for example:

• when the flagd was evaluated
• then the resolved details value should be ...

To improve clarity and consistency, we should consider step naming that reflects what is being validated and follow the project's usual wording pattern with should be:

• If the test checks for an emitted event after an action (thrown by the implementation), use: then the event should be fatal.
• If the test checks the client's internal state (handled by the SDK) after an action, use: then the client state should be fatal.

Note: The client state is managed and checked by the SDK, while the fatal event is emitted by the implementation. Use the appropriate step name depending on which aspect is being verified.

Suggested actions:

• Review the relevant Gherkin scenarios and clarify whether the check is event-based or state-based.
• Update the step name to match the should be pattern (e.g., then the event should be fatal if testing for an event, or then the client state should be fatal if testing for state).
• Update Gherkin scenarios and step definitions accordingly.

This will improve test readability, consistency, and alignment with established project conventions.

[aepfli]

relates to #302