fix(orchestrator): early-bind gRPC port + serve /health during startup reclaim

[AdaAibaby]

What

Bind the orchestrator's service port (GRPC_PORT) and start the HTTP /health server before the potentially long sandbox-runtime initialization (startup reclaim + network pool populate), instead of after it.

Refs #3615 (Solution A).

Why

On a host that previously ran many sandboxes and was drained to 0, a large number of ns-* network namespaces can remain in /run/netns (leaked slots). On the next orchestrator upgrade/restart, startupreclaim.Run → network.ReclaimLeakedSlots tears these down one namespace at a time, and the whole reclaim chain runs before cmux binds the port. With thousands of residual namespaces this takes 20–30 minutes, during which:

• the port is closed → Nomad health checks fail with connection-refused,
• the node reads as failed (not starting) → restart churn.

How

• pkg/service/info.go: ServiceInfo now starts Unhealthy instead of Healthy.
• pkg/factories/run.go:
  • Create the cmux server, match the HTTP and gRPC listeners, and start cmux.Serve() + the HTTP /health server early, right after the closers slice is set up.
  • The long init chain (acquireOrchestratorLock stays first and blocking → startup reclaim → NewStorageLocal → pool populate → server.New → RegisterService) runs afterwards, unchanged in order.
  • After all RegisterService calls complete, grpcServer.Serve(grpcListener) is started and the status flips to Healthy.
  • The late /upload handler (local build storage, only created during template-manager setup) is wired through an atomic.Pointer[localupload.Handler] so the HTTP mux stays immutable once serving; it returns 503 until the real handler is stored.

Effect

The port is open the whole time and /health answers 503 until the runtime is ready, so Nomad treats the node as starting rather than failed. No new work is routed to the node until it flips to Healthy (edge/service discovery gates on CanAcceptNewRequests, which is Healthy-only).

Correctness notes

• gRPC ordering: gRPC forbids RegisterService after Serve(). The gRPC listener is matched at early-bind but only Served after all registrations complete; connections arriving in between buffer in the cmux matcher. During that window /health is 503, so the edge should not be sending gRPC traffic here.
• Lock stays first: acquireOrchestratorLock (flock) remains first and blocking — it is the single-instance guard, and startup reclaim mutates host-level netns/iptables so it must hold the exclusive lock.
• Drain path: the shutdown drain only acts when status is Healthy/Standby, so a shutdown received mid-init (still Unhealthy) correctly skips draining a node that never became ready.

Testing

Built and tested on Linux (linux/amd64, go1.26.3):

• go build ./... for packages/orchestrator — full binary compiles.
• go vet ./pkg/factories/ ./pkg/service/ ./pkg/healthcheck/ — clean.
• go test ./pkg/factories/ ./pkg/service/ — pass.
• go test ./pkg/sandbox/network/... ./pkg/startupreclaim/... — pass (covers the reclaim path this PR reorders around).
• Full orchestrator test tree compiles (go test -run=^$ ./...).

Follow-ups (not in this PR)

• Solution B from Orchestrator GRPC_PORT takes 20-30 min to bind on startup when /run/netns has many residual ns-* from a previously drained node #3615: parallelize the per-slot teardown loop in ReclaimLeakedSlots to cut reclaim wall-time. Complementary to this change.
• Root-cause question in Orchestrator GRPC_PORT takes 20-30 min to bind on startup when /run/netns has many residual ns-* from a previously drained node #3615: whether such a large ns-* leak on drain is expected, or points to a normal-operation teardown path that should have cleaned these up.