http: HEAD requests to GET routes, including /.well-known/alive and /.well-known/health, return 404 #4423

Summary

HEAD requests to GET routes return 404, including /.well-known/alive and /.well-known/health, while GET on the same paths returns 200. RFC 9110 §9.1 requires general-purpose servers to support HEAD wherever they support GET, with the same status and headers and no body.

Reproduction

Any GoFr app:

$ curl -s -o /dev/null -w '%{http_code}\n' localhost:8000/.well-known/alive
200
$ curl -sI localhost:8000/.well-known/alive | head -1
HTTP/1.1 404 Not Found
$ curl -sI localhost:8000/.well-known/health | head -1
HTTP/1.1 404 Not Found
$ curl -sI localhost:8000/user/1 | head -1        # an app.GET route
HTTP/1.1 404 Not Found

Root cause

• pkg/gofr/http/router.go:447 registers each route with Methods(method).Path(pattern), so a GET route matches only GET.
• A HEAD request falls through to the catch-all, which answers 404.
• There is no app.HEAD. Only the static file handler accepts HEAD (router.go:529-535). Its comment already notes that answering 404 for a method on a path where GET is 200 "is its own lie".

Impact

• Uptime monitors, load balancer health checks and link checkers that probe with HEAD see GoFr services as down. Many monitoring tools use HEAD by default.
• curl -I and HTTP caches get wrong answers.
• Open PR fix(http): respond with 405 Method Not Allowed for a wrong method on a registered path #4104 (405 for a wrong method) would turn this into a 405, which is still wrong for HEAD on a GET route.

Suggested fix

• In Router.Add, register GET routes as Methods(http.MethodGet, http.MethodHead). net/http already drops the response body for HEAD.
• Add a test asserting HEAD /.well-known/alive and HEAD on a user GET route both return 200 with an empty body.