#278 made a failed scheduled poll tear down the interval via
stopPollingForDefinitions(). The reasoning was that a caller who sees
the error can restart, and that silent retries hide permanent failures
(revoked token, deleted project).

In practice the common caller starts polling once at boot and never
re-checks. A single transient blip — a 500, a DNS hiccup — then freezes
flag definitions at their last-fetched values for the life of the
process, with nothing but one error line to show for it. That trades a
loud recoverable condition for a silent unrecoverable one.

It was also a deliberate divergence from every other server SDK: Go,
Python, Ruby, and Java all log and continue. Ruby's provider even
carries a comment explaining why a transient failure must not stop
polling. Node was the only outlier.

Restore log-and-continue. The interval survives a failed tick and the
next one recovers on its own. Permanent failures still log on every
tick, which is the signal callers actually watch for.

Retitles the pinning test to "keeps polling when a refresh fails" and
extends it: after the failing tick, clearInterval is not called,
pollingInterval and _startPromise are intact, and a subsequent
successful tick confirms recovery.

The SDK-81 concurrent-start guard from #278 is unchanged.

Linear: SDK-81