Please address the comments from this code review:

## Overall Comments
- The new `WithStoreProvider` on `detector.Builder` now overlaps with the existing `WithXStore`/`With*LabelProvider` methods; consider either deprecating the more granular setters or documenting/preventing mixed usage so it’s clear which values win if both are called.
- There are now two different `StoreProvider` types (the new `detector.StoreProvider` interface and the existing Kubernetes `StoreProvider` struct) with the same name in different packages; consider renaming one (e.g. `DetectorStoreProvider` or `ReadOnlyStoreProvider`) to reduce ambiguity when reading or searching the codebase.

## Individual Comments

### Comment 1
<location path="sensor/common/detector/builder.go" line_range="26-34" />
<code_context>
 	"github.com/stackrox/rox/sensor/common/updater"
 )

+// StoreProvider provides access to the stores needed by the detector.
+type StoreProvider interface {
+	Deployments() store.DeploymentStore
+	ServiceAccounts() store.ServiceAccountStore
+	NetworkPolicies() store.NetworkPolicyStore
+	Nodes() store.NodeStore
+	Registries() registry.Provider
+	ClusterLabels() scopecomp.ClusterLabelProvider
+	NamespaceLabels() scopecomp.NamespaceLabelProvider
+}
+
</code_context>
<issue_to_address>
**suggestion:** Consider reusing or embedding the existing store.Provider to avoid overlapping store-provider abstractions.

This new StoreProvider overlaps with sensor/common/store.Provider (Deployments, ServiceAccounts, NetworkPolicies, Nodes, Registries). To avoid drift between two similar interfaces, consider either accepting store.Provider here and defining a separate interface only for the label providers, or embedding store.Provider in StoreProvider and adding ClusterLabels/NamespaceLabels. That keeps the API smaller and reduces divergence risk.
</issue_to_address>