[jonasz-lasut]

What

Adds serve_service_with_health, which returns the gRPC HealthReporter alongside the server future instead of reporting the service as serving up front. The service starts as NOT_SERVING; the caller flips it with set_serving when ready. serve_service (#1) becomes a delegate that flips to serving immediately, so existing behavior is unchanged. HealthReporter is re-exported so callers do not need a direct tonic-health dependency.

Why

A function that does start-up work - warming module caches, compiling wasm - should listen immediately and let probes read NOT_SERVING while it warms: a closed port reads as a crashed process (connection refused) and can restart-loop the pod, while NOT_SERVING on an open port is exactly the state gRPC health exists to express. Requests arriving mid-warm-up are served (cold) regardless of health status - health is what probes read, not a gate. This is the readiness shape function-wasm's Go runtime has; the handle lets the Rust runtime match it.

Notes

• The server future is returned rather than awaited so the caller holds the reporter before anything listens; + use<S> precise capturing keeps the future 'static (it borrows nothing from Args), so it can be tokio::spawned.
• The integration test asserts the full sequence: NOT_SERVING at start, RunFunction answered while not serving, SERVING after the flip.

Slated for 0.3.0 together with #1.

[jonasz-lasut]

Superseded by the ServerBuilder rework in #3: a builder composes custom codec, caller-owned health and extra services in one chain instead of accumulating free functions. The health-reporter semantics (NOT_SERVING start, requests served regardless, caller flips) carry over as ServerBuilder::health_reporter.