fix(prometheus): dedupe memory scrape series (skyhook-io#654)

fix: server-side apply, idempotent Helm install, RBAC pre-flight (SKY…

…-843) (skyhook-io#605)

cache: patience-window + minimal-set first paint (skyhook-io#544)

cache: patience-window + minimal-set first paint (skyhook-io#544)

cache: patience-window + minimal-set first paint (skyhook-io#544)

cache: patience-window + minimal-set first paint (skyhook-io#544)

docs(claude): forbid ticket/PR refs in code comments

docs(claude): forbid ticket/PR refs in code comments

fix(drawer): populate Recent Events and bias toward K8s events (skyho…

…ok-io#547) (skyhook-io#556)

* fix(drawer): Recent Events section now populates and stays signal-rich (skyhook-io#547)

The Recent Events section in the resource detail drawer was always empty.
Three independent bugs combined to cause this; once they were fixed, a
fourth UX issue was addressed: K8s events were being drowned out by
high-frequency informer status flips on flapping resources.

Root causes fixed:

1. useResourceEvents queried /api/changes with kind="pods" (URL form), but
   the timeline store keys events by K8s Kind ("Pod") and did not pass
   include_managed=true, so the default preset's IsManaged() filter dropped
   Pod/Event/ReplicaSet entries entirely.
2. pluralToKind("pods") was returning "PodMetrics" because initNavigationMap
   let the metrics.k8s.io API resource (also named "pods") overwrite the
   canonical Pod mapping. Fixed to be first-wins for builtins. This was a
   broader bug that likely affected other kind-based lookups too.
3. The package's WorkloadView never plumbed the events array into
   ResourceRendererDispatch (in either drawer or expanded mode), so even a
   correct query never reached EventsSection. Added resourceFocusedK8sEvents
   and resourceFocusedUpdates props through the chain.

UX improvements on top:

- K8s events and informer/historical updates are now fetched in two separate
  React Query calls with separate limits (500 vs 50). On a flapping pod the
  k8s_event stream cannot be starved out by an unbounded update stream.
- EventsSection shows K8s events by default with a "Show N changes" toggle
  to fold in resource updates, with a tooltip explaining the distinction.
  Default is K8s-only because for most users those are the actionable
  signals (Pulling, Failed, BackOff, Killing, etc.).
- Backend /api/changes now accepts a sources= query param (already supported
  internally by the timeline store, just wasn't exposed).

Also removes web/src/components/shared/ResourceRendererDispatch.tsx, a
wrapper that nothing imported.

* review fixes: surface query errors, validate sources, tighten types

- useResourceEvents now returns k8sError/updatesError; EventsSection
  renders them inline so a partial query failure doesn't render as
  "no events" (same silent-failure class as the original skyhook-io#547 bug).
- /api/changes rejects invalid sources= values with 400 instead of
  silently returning [] (typos like "k8sevent" looked like empty).
- ResourceRendererDispatch: events?: any[] -> TimelineEvent[]; same
  for updates. No reason for any[] now that TimelineEvent is in scope.
- Add initNavigationMap regression test for the metrics.k8s.io/Pod
  collision — easy to "clean up" the first-wins guard without realizing.
- Trim a few JSDoc/inline comments that narrated WHAT or referenced
  the calling site.

fix(resources): pass basename-relative basePath so kind URL syncs in …

…Cloud (skyhook-io#558)

PR skyhook-io#552 fixed the standalone /resources redirect path but didn't address
the underlying mismatch in embedded mode: basePath was constructed with
the basename ('/c/{cluster}/resources'), while locationPathname comes
from react-router's useLocation which strips the basename
('/resources/deployments'). getInitialKindFromURL's
pathname.startsWith(basePath + '/') check therefore never matched in
Radar Cloud, so every navigation fell through to the default Pod kind —
URL would update to /resources/deployments, but the table kept rendering
Pods.

basePath is now '/resources' regardless of basename. URL writes still go
through handleNavigate, which strips any leading basename before
react-router re-applies it, so Cloud bookmarks and history-rewrites stay
correct.