SRDX Viewer Decode Path + HTTP Fetch — 0.7.0 T2

sigil-apps ad28b7d closes two critical 0.7.0 loops. apps/srdx/viewer.sg (IS_SCENE) closes the SRDX 1.0 decode loop: the viewer now has an inline BGRA32 decoder that blits dirty-rect frames directly to the raw framebuffer layer and composites the Lumen chrome on top. This is the Apps-side receiver for srdx_relay.sg frames (OS, coming next) — no ABI change needed when the OS relay lands. apps/net/http_fetch.sg (arm-el0) closes the HTTP dark lane: it exercises the full HTTP/1.1 redirect chain (GET → 301 → GET → 200 → body) using the same inline request builder as the OS cc0 net stack, wiring to live Cap<NetConn> syscalls when the Kernel grants net caps.

viewer.sg — SRDX decode path (IS_SCENE)

The SRDX viewer was already in the App (Sessions Manager, srdx_negotiate_* wired in f6ef9a4). What was missing was the actual decode path — the pipeline that takes an incoming SRDX encoded frame, decodes it, and blits it to the display. ad28b7d wires this in.

srdx_decode_inline: scalar BGRA32 dirty-rect decoder. For each tile in the incoming SRDX frame:

1. Check the tile's dirty bit in the frame header
2. If dirty: decode the 64×64 tile payload (raw BGRA32, no compression in the loopback test path) into the raw fb layer
3. Call poke32 per pixel into the framebuffer at the tile's (x,y) offset

After all tiles are decoded, the Lumen chrome is composited over the raw fb layer — nav bar, session status panel, and the SRDX stream canvas are all compositor layers drawn on top. The viewer is IS_SCENE in build.sh (appears in the demo reel and IS_SCENE build target).

The left panel surfaces live decode state:

Canvas position: item (164,0,440,300) = screen coordinates (187,63) with size 438×298. The fb blit aligns exactly to this canvas boundary — the dirty-rect decoder writes only inside this region.

ABI stability: srdx_relay.sg (OS, coming next) will feed frames directly into this viewer via the same SRDX frame wire format. No ABI change on the viewer side — the relay just becomes the frame source instead of a test fixture.

Build: ./build.sh srdx_viewer shot — runs the viewer demo scene and saves a screendump.

http_fetch.sg — HTTP/1.1 redirect-follow + parse (arm-el0)

apps/net/http_fetch.sg is the arm-el0 (real hardware / EL0 cap ABI) counterpart to the OS cc0 http_fetch.sg that shipped in 0ecc2f6. It exercises the full HTTP/1.1 redirect chain — the "dark lane" that the OS net stack tests with loopback stubs, now tested with the real arm-el0 cap ABI.

Parser helpers, composed inline rather than as separate surface rows:

• find_lf(buf, off, len) — find next \n from offset; used for line-by-line header parse.
• find_body(buf, len) — find \r\n\r\n separator; returns offset of body start.
• find_location(buf, len, out, outlen) — extract Location: value from redirect response.
• print_headers(buf, len) — print all headers to debug output.

This covers the OS "dark HTTP lane" — the path where the app layer exercises HTTP without going through a JS runtime. When cc0/JS ships, JS fetch() calls go through http_fetch.sg via the Net process. The arm-el0 test validates the ABI independently.

apps/net/http_fetch.sg (arm-el0)
  GET /
    → Cap<NetConn> sys109 (connect) + sys110 (send)
    ← 301 Location:/new
      find_location() → /new
      sys112 (close)
  GET /new
    → sys109 (connect) + sys110 (send)
    ← 200 OK
      find_body() → body offset
      print_headers() → Content-Type, Content-Length
      body excerpt printed

What this closes

srdx_relay.sg on the OS side is the remaining 0.7.0 SRDX closure. When it lands, the relay becomes the frame source for the viewer — no ABI change, the wire format is already locked by ad28b7d.