Introduce health-check-interval module parameter

[IvanBorislavovDimitrov]

Description:

Add support for the MTA module-level parameter health-check-interval, keeping feature parity with the underlying CF capability. Authors of an MTA descriptor can now configure how often the platform issues the liveness health check for an application, mirroring the existing readiness-health-check-interval plumbing:

modules:
  - name: my-app
    type: application
    parameters:
      health-check-interval: 15

Until recently this was not possible because the new CF Java client did not expose the field; the latest CF Java client adoption unblocks the change.

What changed

• Register the new parameter constant in SupportedParameters and add it to MODULE_PARAMETERS so the descriptor whitelist accepts it.
• Parse the value in StagingParametersParser and forward it through the Staging value object.
• Forward the value to the CF Cloud Controller in CloudControllerRestClientImpl#buildHealthCheck so create and update flows propagate it via Data.builder().interval(...).
• Round-trip the value when reading processes from CF in RawCloudProcess#derive, with a matching getHealthCheckInterval() accessor on CloudProcess.
• Surface the parameter in AdditionalModuleParametersReporter via a new MTA_USES_HEALTH_CHECK_INTERVAL_PARAMETER message constant so usage is logged alongside the other tracked module parameters.

Tests

• multiapps-controller-client/.../RawCloudProcessTest — 4 cases covering derive round-tripping health-check-interval (present, absent, with the readiness counterpart, and edge values).
• multiapps-controller-process/.../AdditionalModuleParametersReporterTest — 7 cases exercising the new reporter branch and confirming the log message is emitted only when the parameter is set.
• multiapps-controller-core/.../StagingParametersParserTest — 3 added cases for parsing health-check-interval from module parameters.

Notes for the reviewer

• A bespoke unit test for the private buildHealthCheck helper on CloudControllerRestClientImpl was intentionally not added: the method is private and the readiness counterpart has no unit-test precedent. The read-side round-trip is covered by RawCloudProcessTest.

Issue:

Jira: LMCROSSITXSADEPLOY-3316

[IvanBorislavovDimitrov]

MTA Quality Report — cloudfoundry/multiapps-controller PR #1851

Jira: LMCROSSITXSADEPLOY-3316 — Introduce Health check interval
Backlog alignment: PASS

• Implements Jira scope? yes — adds the health-check-interval module parameter end-to-end (constant + whitelist, StagingParametersParser, Staging value object, CloudControllerRestClientImpl#buildHealthCheck, RawCloudProcess#derive, AdditionalModuleParametersReporter log line) plus matching unit tests, exactly mirroring the readiness-counterpart pattern the ticket calls for.
• Changes outside Jira scope? no — every hunk in the 11 changed files is in service of the new parameter; no unrelated refactors, dependency bumps, or behavioural changes.

---

Code Review

⚠️ Subagent failed: code-reviewer subagent could not be spawned in this environment (no Task/Agent tool available to the orchestrator). The diff was not analyzed for bugs or CLAUDE.md compliance. Re-run from an environment that exposes the Task tool to populate this section.

---

Security

⚠️ Subagent failed: security-reviewer subagent could not be spawned in this environment (no Task/Agent tool available to the orchestrator). The diff was not analyzed for OWASP / MTA-specific vulnerabilities. Re-run from an environment that exposes the Task tool to populate this section.

---

SonarCloud

SonarCloud check Build and analyze (run id 78853557958) is still in progress at the time of this scan — annotations are not yet available. The check status snapshot:

Check	Status	Conclusion
Build and analyze (SonarCloud)	in_progress	—
Analyze (java) (CodeQL)	in_progress	—
build	in_progress	—
Check Commit Message	completed	success
EasyCLA	completed	success

Annotations unavailable: SonarCloud has not yet finished. Re-run the quality scan once the check completes to fetch per-line annotations.

---

Dependency CVEs

✅ No new CVEs — this PR does not modify any dependency files (pom.xml, build.gradle, lockfiles).