Bound remaining unbounded `context.Background()` Docker calls (web/health, cli/docker_config_handler, cli/doctor)

[CybotTM]

Surfaced during the audit of #608 / #611. Same bug class: unbounded contexts on Docker SDK calls that hang Ofelia when the daemon is reachable-but-wedged.

#611 bounded the construction-time NegotiateAPIVersion. Three more sites still pass context.Background() to Docker calls:

File:Line	Call	Symptom on wedged daemon
web/health.go:116	dockerProvider.Ping(ctx) and Info(ctx) in checkDocker	/health and /ready endpoints hang; monitoring fails to detect the wedge
cli/docker_config_handler.go:183	provider.Ping(context.Background()) in buildSDKProvider sanity check	Daemon startup hangs at the post-construction sanity ping
cli/doctor.go:378, 553	Ping, HasImageLocally in ofelia doctor	The diagnostic command hangs — the very tool meant to surface this kind of failure

Suggested fix

Wrap each call in context.WithTimeout(parentCtx, 5–10s) (10s for sanity-checks, 5s for health-endpoint checks where responsiveness matters). For health checks, prefer a per-handler timeout via r.Context() so request cancellation propagates.

Acceptance criteria

• Each call site has a bounded context with defer cancel().
• Health-check timeout is short enough that monitoring sees a non-2xx response within a single scrape interval.
• Tests against a stalling listener (same pattern as fix(docker): bound NegotiateAPIVersion with configurable timeout (#608) #611) prove each call returns within the configured timeout.

Severity

Medium — availability gaps. Health endpoint hanging is the worst of the three because it defeats external monitoring. The startup sanity-check is partially shadowed by the now-bounded NegotiateAPIVersion, but still independently unbounded.