Implement content-type routing #165

Description#

Route fetched resources to the appropriate renderer based on the HTTP Content-Type header. Currently the browser assumes all top-level navigations return HTML. Real web servers return various content types that need different handling.

Requirements#

Content-Type Detection#

Parse the Content-Type HTTP response header (type, subtype, parameters)
Extract the MIME type and charset parameter
Handle missing Content-Type header with content sniffing (per WHATWG MIME Sniffing spec, simplified)
Common sniffing: check for HTML doctype/tags, PNG/JPEG/GIF magic bytes, plain text heuristics

Routing by Type#

text/html — parse with HTML parser, render normally (current behavior)
application/xhtml+xml — treat as HTML (simplified)
text/plain — render as preformatted monospace text (wrap in <pre> internally)
text/css, application/javascript, application/json, text/xml — render as plain text with appropriate labeling
image/png, image/jpeg, image/gif, image/webp — decode and display centered in the viewport
application/pdf — show an unsupported content message (no PDF renderer)
application/octet-stream and other unknown types — show a message indicating the content cannot be displayed

Image Display#

When navigating directly to an image URL, display the decoded image centered on a white/transparent background
Set the page title to the image filename
Support zooming the image (stretch goal)

Charset Handling#

Use the charset parameter from Content-Type to select the text decoder
Fall back to encoding sniffing (BOM, meta tag) for HTML
Default to UTF-8 when no charset is specified

Acceptance Criteria#

HTML pages render normally (no regression)
Navigating to a .txt URL shows plain text in monospace
Navigating to an image URL displays the image centered in the viewport
JSON/JS/CSS files display as readable text
Missing Content-Type header triggers content sniffing
Unsupported types show a friendly message instead of crashing
Unit tests for Content-Type parsing and routing logic