Please address the comments from this code review:

## Overall Comments
- Consider whether `toCompliance` should be buffered, since `forwardToCompliance` is called inline from `ProcessMessage` and an unbuffered channel here could back up Central’s ACK processing if the compliance multiplexer is slow or temporarily blocked.
- In `forwardToCompliance`, you set `Hostname` and `Broadcast` based solely on `resourceID`; double-check that using the VM resource ID as `Hostname` and broadcasting only when `resourceID == ""` matches the expectations of the compliance side consumers (if not, it may be worth adding a small helper or comment clarifying the mapping).

## Individual Comments

### Comment 1
<location path="sensor/common/virtualmachine/index/handler_impl.go" line_range="167" />
<code_context>
 		return errStartMoreThanOnce
 	}
 	h.indexReports = make(chan *v1.IndexReport, env.VirtualMachinesIndexReportsBufferSize.IntegerSetting())
+	h.toCompliance = make(chan common.MessageToComplianceWithAddress)
 	h.toCentral = h.run(h.indexReports)
 	return nil
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider buffering the compliance channel to avoid blocking ACK processing when Compliance is slow or temporarily unavailable.

Because `toCompliance` is unbuffered, `forwardToCompliance` will block until the consumer reads, and `ProcessMessage` is on the hot ACK/NACK path. If Compliance is slow or backpressured, this can stall ACK handling. A small buffer (as used for other internal channels) would mitigate head-of-line blocking while still preserving ordering.

Suggested implementation:

```golang
	if h.toCentral != nil || h.indexReports != nil || h.toCompliance != nil {
		return errStartMoreThanOnce
	}
	h.indexReports = make(chan *v1.IndexReport, env.VirtualMachinesIndexReportsBufferSize.IntegerSetting())
	h.toCompliance = make(chan common.MessageToComplianceWithAddress, env.VirtualMachinesToComplianceBufferSize.IntegerSetting())

```

1. Define `VirtualMachinesToComplianceBufferSize` in the `env` package (or equivalent config) following the same pattern used for `VirtualMachinesIndexReportsBufferSize` (type, default, description, etc.).
2. If there is an existing common buffer size setting for internal VM handler channels (e.g., a shared constant/env var), you may want to reuse that instead of introducing a new one, for consistency.
3. Ensure any unit tests that construct `handlerImpl` or validate channel behavior are updated to account for the buffered `toCompliance` channel (e.g., tests that might have assumed it was unbuffered).
</issue_to_address>

### Comment 2
<location path="sensor/common/virtualmachine/index/handler_impl.go" line_range="240-242" />
<code_context>
+		return
+	}
+
+	select {
+	case <-h.stopper.Flow().StopRequested():
+	case h.toCompliance <- common.MessageToComplianceWithAddress{
+		Msg: &sensor.MsgToCompliance{
+			Msg: &sensor.MsgToCompliance_ComplianceAck{
</code_context>
<issue_to_address>
**suggestion:** Consider handling or at least logging when messages are dropped due to sensor shutdown.

Here, when `h.stopper.Flow().StopRequested()` fires, the select exits and the ACK/NACK is silently dropped. If these messages matter for Compliance accounting, this makes shutdown issues hard to trace. Please add at least a debug log or a counter for messages dropped due to shutdown to make this behavior observable.
</issue_to_address>

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="sensor/common/virtualmachine/index/handler_impl.go" line_range="143" />
<code_context>
-		// TODO(ROX-xxxxx): Implement retry logic or notifying VM relay.
-		// Currently, the VM relay has its own retry mechanism, but it's not aware of Central's rate limiting.
-	}
+	metrics.IndexReportAcksReceived.WithLabelValues(action.String()).Inc()

 	return nil
</code_context>
<issue_to_address>
**suggestion:** Metrics are incremented even for unknown ACK actions, which may pollute metric labels

In `forwardToCompliance`, the `default` branch treats any non-ACK/NACK as unknown and returns early, but the metric is still incremented with `action.String()`. This will introduce label values for unsupported actions that Compliance never processes. Consider only incrementing for known actions or tracking unknown actions in a separate metric/label to avoid polluting the primary series.

Suggested implementation:

```golang

```

`.

Here are the changes:

<file_operations>
<file_operation operation="edit" file_path="sensor/common/virtualmachine/index/handler_impl.go">
<<<<<<< SEARCH
	metrics.IndexReportAcksReceived.WithLabelValues(action.String()).Inc()
=======
>>>>>>> REPLACE
</file_operation>
</file_operations>

<additional_changes>
Inside `forwardToCompliance` (in `handler_impl.go`), adjust the switch that handles the ACK action (the one using `action` and with a `default` branch that returns early on unknown actions):

1. In the `case` branch that handles the ACK action, add:
   ```go
   metrics.IndexReportAcksReceived.WithLabelValues(action.String()).Inc()
   ```
   close to where the ACK is successfully processed (before returning / sending to Compliance).

2. In the `case` branch that handles the NACK action, also add:
   ```go
   metrics.IndexReportAcksReceived.WithLabelValues(action.String()).Inc()
   ```
   again, only after the NACK has been validated as a supported action and is being processed.

3. Do **not** add any metric increment in the `default` branch; keep it returning early for unknown actions. This ensures that `IndexReportAcksReceived` is only incremented for supported actions and avoids label pollution from unknown values.

4. If you want visibility into unsupported actions, consider adding a separate counter, e.g.:
   ```go
   metrics.IndexReportAcksUnknownActions.Inc()
   ```
   inside the `default` branch, using a metric with no `action` label (or with a bounded "reason" label) so it doesn't create unbounded series.
</issue_to_address>