Enhancement: Implement /status subresource for SBOMSyft and SBOMSyftFiltered

### Problem

Currently, the `SBOMSyftStatus` struct is empty, and there is no `/status` REST subresource implemented for `SBOMSyft` and `SBOMSyftFiltered`.

Because of this limitation, downstream consumers (like the vulnerability scanner in `kubevuln`) are forced to store the operational state (e.g., `learning`, `tooLarge`, `incomplete`) as annotations on the object instead of using standard Kubernetes API conventions. This is an anti-pattern for aggregated API servers and makes state tracking difficult for controllers.

### Proposed Solution

1. Add structured fields (`Status`, `StatusReason`, `Limit`) to the `SBOMSyftStatus` struct in the API definitions.
2. Implement a `StatusStrategy` that protects the `Spec` from being modified during `/status` updates.
3. Expose the `NewStatusREST` endpoints in the `etcd.go` registry stores.
4. Wire the endpoints into `pkg/apiserver/apiserver.go`.

### Context

This is a prerequisite to resolving the annotation anti-pattern in `kubevuln`:
* kubescape/kubevuln#496

Start with the API definitions containing SBOMSyftStatus, then inspect the etcd.go registry stores and pkg/apiserver/apiserver.go. Trace how existing status subresources define their strategy and REST endpoints; done means SBOMSyft and SBOMSyftFiltered expose /status, protect Spec during status updates, and store the proposed status fields.

Written by the indexing model from the issue text.