Deployments in use are being disabled

[Phillezi]

Describe the bug
Some deployments are being automatically scaled to 0 replicas, for example those owned by system@kthcloud.com. These deployments are still in use and should not be disabled. The issue is likely related to the stale_resource_cleaner functionality in the stale_resource_cleaner.go.

To Reproduce
Steps to reproduce the behavior:

1. Enable a resource owned by system@kthcloud.com (you might need to update both replicas and something else for it to scale, for some reason it doesnt scale itself when only replicas are updated).
2. Wait for the stale_resource_cleaner to run.
3. Observe that the deployment is scaled to 0 replicas even though it is actively in use.

Expected behavior
Deployments actively in use should not be scaled down or disabled, regardless of the owner. The logic for determining LastAccessedBefore should correctly identify deployments in use and exclude them from cleanup.

Desktop (please complete the following information):

• OS: [N/A]
• Browser: [N/A]
• Version: [N/A]

Smartphone (please complete the following information):

• Device: [N/A]
• OS: [N/A]
• Browser: [N/A]
• Version: [N/A]

Additional context

• The issue appears to stem from how LastAccessedBefore is calculated or used in the stale resource cleaning logic.
• The link to the suspected service: stale_resource_cleaner.go.
• Confirm whether the LastAccessedBefore value is being correctly set and excludes actively used deployments, or how it is set.
• This causes the Status bot to report all deployments as down, since it polls a deployment owned by system@kthcloud.com.

[Phillezi]

Resources accessed_at are only updated when the owner of them accesses it, since the system@kthcloud.com account hasn't accessed the resources owned by them they are interpreted as stale resources.

[Phillezi]

#680 should close this, there is now a way for admins to configure if a resource shouldn't be affected by the stale resource cleaner service.