HEAD requests return 404 instead of honoring GET/HEAD route behavior

[larimonious]

Summary

HEAD requests are returning 404 Not Found in cases where the same route succeeds for GET.

This shows up clearly in live ntnt apps such as template.heylarri.com, where:

• GET / returns 200
• HEAD / returns 404
• GET /health returns 200
• HEAD /health returns 404

Expected behavior

Per RFC 9110 section 9.3.2, HEAD should behave like GET except without the response body when a resource supports GET.

At minimum, ntnt should not return 404 for HEAD when the corresponding GET route exists.

Repro

In an ntnt app with a normal homepage route and health route:

• curl http://127.0.0.1:8080/ -> 200
• curl -I http://127.0.0.1:8080/ -> currently 404
• curl http://127.0.0.1:8080/health -> 200
• curl -I http://127.0.0.1:8080/health -> currently 404

Notes

The async server code appears to have explicit HEAD fallback logic, so this likely means one of:

• the live/runtime path is not consistently using that logic
• route matching is bypassing the HEAD fallback in another code path
• there is a mismatch between interpreter/server route dispatch paths

Proposed fix direction

Audit all HTTP server / interpreter route dispatch paths and make sure HEAD:

1. resolves against explicit HEAD handlers when present
2. falls back to GET when GET exists
3. preserves headers/status and strips the body
4. behaves consistently for dynamic routes and static files