mod request_view

RequestView[origin] borrows method, URL, headers, and body from the connection's read_buf rather than owning them. For a 13-byte plaintext request the difference is invisible (a few String allocations vs. a few offsets); for a 1MB / 16MB multipart upload it's the difference between one memcpy of the whole body and zero.

Pieces in place:

• RequestView[origin] value type (this file).
• parse_request_view(data: Span[UInt8, origin]) raises -> RequestView[origin] parser that scans the request line + headers + body slice without per-header / per-token allocations.
• RequestView.into_owned() raises -> Request materialises a Request for handlers that need to keep request state past one event-loop iteration.

Pieces that come later:

• A ViewHandler trait whose serve_view takes RequestView[origin] directly. Today's Handler.serve signature stays as-is; the reactor's read path can adopt a view-based run_reactor_loop_view once the trait surface lands.
• Replacing _parse_http_request_bytes with the view parser inside the cancel-aware reactor path. The view parser exists here as a standalone public function; the reactor will adopt it once the trait integration is settled.

The shape and public API of RequestView are stable; the integration step is purely "switch the reactor's internal call site," which lands without breaking handlers. The integration portion is a follow-up alongside the reactor surgery.

Example:

var raw = "GET /a?q=1 HTTP/1.1
Host: x

".as_bytes()
    var view = parse_request_view(Span[UInt8, _](raw))
    print(view.method) # GET
    print(view.url) # /a?q=1
    print(view.headers.get("Host")) # x
    print(len(view.body)) # 0

    # Materialise an owned ``Request`` if you need one:
    var owned = view.into_owned()