fix(api): check readiness immediately on startup

[wangjingshuiku]

Related Issues

No issue. This is a small correctness fix for the existing /health/readyz endpoint.

Related context: #12587 documents that /health/readyz is intended to be used as a Kubernetes readiness endpoint.

Proposed Changes

• Run the readiness check once immediately when NewReadyHandler starts, rather than waiting for the first one-minute ticker interval.
• Keep the existing one-minute polling interval and readiness criteria unchanged.
• Add a regression test verifying that an already-ready node becomes healthy without waiting for the first periodic tick.
• Add an entry to the UNRELEASED bug fixes section of CHANGELOG.md.

Additional Info

HealthHandler starts in the unhealthy state. Previously, NewReadyHandler only evaluated NetAutoNatStatus and NodeStatus after the first time.Minute ticker event. As a result, an otherwise-ready node could return HTTP 503 from /health/readyz for up to one minute after the handler was created.

This can unnecessarily keep a healthy Lotus node out of a Kubernetes Service or load-balancer pool during startup.

The readiness criteria themselves are unchanged. This change only performs the same check once immediately before continuing with the existing periodic checks.

PR #8692 describes the health endpoints as being useful for Kubernetes readiness and liveness probes. Issue #12587 also confirms that /health/readyz is intended specifically as a Kubernetes readiness endpoint.

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions.
• Updated CHANGELOG.md.
• No new user-facing feature or documentation is required.
• Tests exist for the behavior change.
• CI is green.

[Kubuxu]

Do you observe the check succeeding immediately after applying this patch? Some machinery might still be starting when the handler is created, causing the immediate check to fail.