fix: suppress error log for unsupported HTTP methods (HEAD, POST, etc.)

[lennney]

Closes #1677.

Problem

When a non-GET HTTP request (HEAD, POST, OPTIONS, etc.) hits a websockets
server, it causes a noisy ERROR opening handshake failed log with full
traceback. The connection is already being closed cleanly, so the error log
is misleading but not actionable.

What #1684 got right and wrong

PR #1684 correctly identified the fix but was rejected for calling
reject() from the low-level parser — a layering violation as noted by
@aaugustin. The problem is real and affects production servers that get
hit by bots and health checkers.

This fix

1. http11.py: Change the unsupported-method exception from generic
   ValueError to InvalidHandshake — semantically accurate since an
   unsupported method IS an invalid handshake.

2. asyncio/server.py + sync/server.py: In handshake(), suppress
   the re-raise when handshake_exc is an InvalidMessage caused by an
   InvalidHandshake. The connection is already being closed cleanly by
   send_eof() — re-raising only causes an ERROR log that's noise.

3. Test update: test_parse_unsupported_method now expects
   InvalidHandshake instead of ValueError.

What's NOT changed

• Junk data (e.g. HELO) still produces InvalidMessage without
  InvalidHandshake as cause → still logged as ERROR (security-relevant)
• Parser still returns 400 BAD_REQUEST for all handshake failures
• No response body is sent for unsupported methods (connection closes
  cleanly, same as before — just no ERROR log)

Testing

• tests/test_http11.py: 98 passed
• tests/test_server.py: all handshake tests passed
• tests/asyncio/test_server.py: test_junk_handshake still logs ERROR
  (junk data), HEAD/OPTIONS logged at DEBUG
• Manual: HEAD/POST requests → connection closed cleanly, no ERROR in logs
• Manual: Normal WebSocket GET handshake → unaffected

[aaugustin]

• Did you just throw an AI at the problem, or did you actually think about it?
• If you thought about it, could you explain why you didn't follow the direction given in the original issue (return HTTP 405)?

[lennney]

Follow-up to 3a6ee61 — the earlier commit suppressed the error log but
the client still just got a dropped connection with no HTTP response.
This closes the loop by sending 405.

I looked at how gorilla/websocket and ws handle this — both return 405
(StatusMethodNotAllowed / abortHandshake with 405). ServerProtocol.parse()
is the equivalent entry point, same place where gorilla's Upgrade() and
ws's handleUpgrade() check the method.

The check goes after the existing InvalidHandshake exception handler so
we don't touch the valid-error paths (ValueError for bad protocol,
EOFError for truncated connections, etc.). reject() and send_response()
were already there, so it's 4 lines of new logic.

[aaugustin]

Look, I'm not interested in talking with an AI over GitHub comments; if I want to use Claude Code, I'll use it directly.