http_resp_buf rendered as ASCII on C64 screen (missing PETSCII translation) #28

Summary

After a successful HTTPS GET, the C64's display routine writes
http_resp_buf bytes directly into screen RAM. Because screen RAM
uses C64 screen codes (not ASCII), the decrypted response body
(HELLO FROM TLS SERVER) renders as graphics characters instead of
readable text.

Details

• The response bytes in http_resp_buf are correct — this is verified
  server-side (the C64 sent the expected GET and the TLS 1.3 record
  layer decrypted the 200 response body correctly). Only the on-screen
  rendering is wrong.
• The boot banner already does the right translation — see the
  banner text path in src/boot.s. The HTTP response display path
  needs the same ASCII -> screen-code conversion applied before the
  sta $0400,x (or equivalent) writes.

Severity

Cosmetic. Networking / TLS / HTTP parsing are all correct. This only
affects what the user sees on the C64 screen after a successful GET.

Suggested fix

Apply the same ASCII -> screen-code translation that the boot banner
uses when writing http_resp_buf bytes to screen RAM. A short lookup
table (or the standard $20/$40/$60 bias rules) covers the printable
ASCII range needed for typical HTTP response bodies.