fix(MAJORLEA-008): CU-86akdypzw openframe-config startupProbe/livenessProbe target a static XML resource, not Spring Actuator health endpoints

[flamingo]

Closes findings from rule MAJORLEA-008 — openframe-config startupProbe/livenessProbe target a static XML resource, not Spring Actuator health endpoints.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🟡 70 medium	openframe-config startupProbe/livenessProbe target a static XML resource, not Spring Actuator health endpoints	manifests/platform/openframe-config/templates/deployment.yaml:62

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: c1688cba-c9bc-481b-b917-2b7f45403ab4

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akdypzw OpenFrame Kubernetes manifest hardening secondary (12 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

1 finding(s) fixed in this draft — 1 explained inline on the diff.

[flamingo]

🦩 🟠 openframe-config startupProbe/livenessProbe target a static XML resource, not Spring Actuator health endpoints

In the openframe-config Deployment's container spec, changed startupProbe.httpGet to target path: /actuator/health on port: management (previously /xml/shared-logback-spring.xml on port: http), and changed livenessProbe.httpGet to target path: /actuator/health/liveness on port: management (same substitution). This aligns startup/liveness checks with Spring Actuator health endpoints exposed on the management port (8889), per MAJORLEA-008. The readinessProbe was left untouched (still probing the static XML on the http port) since the finding only calls out startup/liveness probes; if readiness should also move to actuator (e.g. /actuator/health/readiness), that would require confirming the readiness probe's semantic intent and is not covered by the given finding text, so it was left unchanged to keep the diff minimal.

🤖 Prompt for AI agents

In manifests/platform/openframe-config/templates/deployment.yaml around line 62, review and complete this code-review fix: openframe-config startupProbe/livenessProbe target a static XML resource, not Spring Actuator health endpoints.
What the draft fix changed: In the openframe-config Deployment's container spec, changed `startupProbe.httpGet` to target `path: /actuator/health` on `port: management` (previously `/xml/shared-logback-spring.xml` on `port: http`), and changed `livenessProbe.httpGet` to target `path: /actuator/health/liveness` on `port: management` (same substitution). This aligns startup/liveness checks with Spring Actuator health endpoints exposed on the management port (8889), per MAJORLEA-008. The `readinessProbe` was left untouched (still probing the static XML on the http port) since the finding only calls out startup/liveness probes; if readiness should also move to actuator (e.g. `/actuator/health/readiness`), that would require confirming the readiness probe's semantic intent and is not covered by the given finding text, so it was left unchanged to keep the diff minimal.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 70 medium — react 👍/👎 to teach the reviewer