Incremental RBAC scrape can soft-delete valid config_access when triggered by RBAC events or RBAC watch

[adityathebe]

When kubernetes.rbac_config_access is enabled, incremental Kubernetes scrapes can incorrectly soft-delete valid RBAC-derived data because incremental batches are partial.

Incremental RBAC processing can be triggered for Role/RoleBinding resources through both paths below:

1. Event path (enabled by default)
   Event is always watched. If an event has involvedObject as Role, RoleBinding, ClusterRole, or ClusterRoleBinding, incremental flow fetches and re-enqueues that RBAC object for scraping.

2. Manual watch path
   If spec.kubernetes[].watch is explicitly configured to include RBAC kinds (Role, RoleBinding, ClusterRole, ClusterRoleBinding), informer updates for those resources directly trigger incremental scrape batches.

Incremental RBAC extraction only sees objects present in the current batch, so emitted ExternalRoles / ConfigAccess can be a subset. Stale-entity cleanup still runs scraper-wide and treats the current batch’s seen IDs as authoritative for that run.

Impact: valid RBAC access graph can be removed during normal incremental activity, causing incomplete/incorrect access visibility for the scraper.