[shell-operator] fix: prevent silent empty snapshots from lost kubernetes monitors 1.17

[ldmonster]

Overview

Fixes a class of failures where a hook keeps running "successfully" while one of its
kubernetes bindings silently feeds it empty snapshots, because the binding's
monitor or its shared informer was lost and never restored.

Two root causes are addressed, plus a hardening fix for the events goroutine.

What this PR does / why we need it

1. EnableKubernetesBindings is now idempotent and self-healing
(pkg/hook/controller/kubernetes_bindings_controller.go)

Previously the method bailed out early when len(BindingMonitorLinks) == len(KubernetesBindings),
comparing only counts. A DisableKubernetesBindings racing with Enable could leave a
binding whose link exists but whose monitor is gone — after that, every
SnapshotsFor call for the binding returned empty while the hook continued to succeed.

Now each binding is checked individually: a missing monitor is re-added and restarted
(guarded against duplicates), and a Synchronization BindingExecutionInfo is always
returned for every binding, so a repeated call after a partial failure never drops the
Synchronization run that populates hook snapshots. Additionally, SnapshotsFor logs a
warning when a configured binding has no live monitor, making the previously silent
empty-snapshot state observable.

2. Shared informer lifetime now belongs to the FactoryStore, not its first consumer
(pkg/kube_events_manager/factory.go)

Factory contexts were derived from the context of whichever consumer happened to create
the shared factory first — stopping that consumer killed the shared informer for every
other monitor using the same (namespace, GVR) index. Worse, the dead factory stayed in
the store and was happily reused: HasSynced() on a stopped informer returns true,
event handlers can no longer be added, and the consumer got a snapshot that never updates.

Now:

• factory contexts derive from the store owner's (KubeEventsManager) context;
• Start detects a factory whose informer goroutine has exited, drops it, and builds a
  fresh one;
• Reset cancels informer goroutines instead of leaking them detached;
• AddEventHandler errors fail Start with an error instead of being logged and ignored
  (a consumer without a handler would degrade silently);
• the cache-sync wait was moved outside the store lock, so one slow initial LIST no longer
  serializes Start/Stop of every other informer.

3. Panic isolation for event callbacks
(pkg/shell-operator/manager_events_handler.go)

Schedule and kube-event callbacks now run with recover() (mirroring
TaskQueue.processOne), so a panicking hook dispatch logs a warning with a stack trace
instead of killing the events goroutine — and with it the whole process.