"Last scan" timestamp shows object creation time and never updates (uses immutable `metadata.creationTimestamp`)

## Summary
The "Last scan" field shown on workload/image detail pages does not reflect when a workload was actually last scanned. It reads `metadata.creationTimestamp`, a Kubernetes-native field set once when the object is first created and never updated on subsequent writes. So for any long-lived workload, "Last scan" permanently freezes at the date the CRD object was first created — even while the scan results themselves (`spec.controls`) are being correctly refreshed on every rescan.

## Where
- `src/compliance/WorkloadScanDetails.tsx:78-79`
- `src/vulnerabilities/WorkloadScanDetails.tsx:63-64`
- `src/vulnerabilities/ImageDetails.tsx:37-38`

All three do the same thing:

```ts
{
name: 'Last scan',
value: .metadata.creationTimestamp,
},
```

## Evidence from a live cluster
Observed a `WorkloadConfigurationScan` object whose `metadata.resourceVersion` climbed from 3 to 167+ over several days — proof it was rewritten with fresh results repeatedly — and whose `kubescape.io/sync-checksum` annotation changed accordingly each time. `metadata.creationTimestamp` never changed across any of those rewrites. The "Last scan" column showed the same stale date the entire time, even though scanning was working correctly.

Checked the full raw JSON of a live `WorkloadConfigurationScan`; the only timestamp anywhere in it is `metadata.creationTimestamp`:

```json
"metadata": { "creationTimestamp": "...", "annotations": {...}, ... },
"spec": { "controls": {...}, "relatedObjects": [...] }
```

No `spec.metadata.report.createdAt`-style field exists on this CRD — unlike `SBOMSyft`, which does have one, correctly read by `SBOMDetail.tsx:40` (`sbomSyft.spec.metadata.report.createdAt`).

## Suggested fix
1. Upstream (kubescape operator/storage writer) should stamp a real "last evaluated" timestamp into `spec` on every scan write for `WorkloadConfigurationScan(Summary)` and `VulnerabilityManifest(Summary)`, matching the pattern `SBOMSyft` already uses.
2. Once available, update the three call sites above to read that field instead of `metadata.creationTimestamp`.
3. Until then, the label is actively misleading — at minimum it should be relabeled ("Created") rather than claim to be a scan time it demonstrably isn't, since it causes users to wrongly conclude scanning is broken/stale when it's actually working.

## Environment
- Plugin: v0.11.2 (bug present unchanged on current `main` @ `711ed28`; originally introduced in `71afeee`, 2024-09-19)
- Kubescape: chart v1.40.1, scanner v4.0.14

Start with the three named WorkloadScanDetails.tsx and ImageDetails.tsx call sites, then compare their timestamp usage with SBOMDetail.tsx:40. Inspect the live WorkloadConfigurationScan and VulnerabilityManifest payloads and the upstream writer behavior; done means the displayed value reflects the latest scan, or is accurately labeled as creation time if no scan timestamp is available.

Written by the indexing model from the issue text.