fix(workloadapi): reconnect watchers on stream EOF

[maxlambrecht]

What

Fix X.509 and JWT Workload API watcher lifecycle for normal stream EOF, explicit cancellation, and retry state.

While a watcher is active, a finite response stream ending normally reconnects per the retry policy instead of being treated as permanent success. Retry/backoff state resets only after a valid update is delivered. User cancellation exits promptly and silently (no on_error, no reconnect). With retries disabled, stream end remains fail-closed via on_error. Public stream method docs now describe this contract.

Why

Watchers previously treated normal EOF as successful completion and could reset retry state just because an iterator ended. That stopped rotation updates after a stream close and could report errors (or reconnect) on explicit cancel. Sources and long-lived callers need fail-closed, cancel-safe, reconnect-on-EOF semantics for both X.509 and JWT streams.

How tested

• Added deterministic X.509 and JWT unit tests with finite fake iterators covering: EOF reconnect + rotated update, silent cancel during/at EOF, retry reset after delivered update, and fail-closed EOF with retries disabled.
• Updated existing finite-stream success/retry tests to cancel intentionally so they do not hang under reconnect.
• Ran: pytest spiffe/tests/unit/workloadapi/test_workload_api_client_fetch_x509.py spiffe/tests/unit/workloadapi/test_workload_api_client_jwt.py (80 passed)