WHAT EXPORT ACTUALLY HAS -- render-params map, and the one missing field.

Breakpoint after the export copy block (0x1B296, file) prints the values the
driver just wrote into the render-params block:

  RP 5a8=0040C000 5d0=00000040 5f0=00000040 610=00000000
     6f8=00000000 718=00000000 738=00000040 758=00000040

Named against the firmware's own dump format strings (file 0x1C8B6..0x1CA79,
which print in this order: floID, flo, active, crop, scale, rotate, mirror,
export, func_count, src_img[][PWIDTH/PHEIGHT], dst_img[][PWIDTH/PHEIGHT],
src_res_id, src_delete, src_base, src_width, src_height, comp format, pGC,
pDraw, drw_x, drw_y, PxlsPerScn, NumOfScns, src_x, src_y, src_w, src_h,
rot_indx, x_mirror, y_mirror):

  rp+0x5a8 = 0x0040C000   src_res_id  -> OUR RESOURCE, correctly resolved
  rp+0x5d0 = 64           src_width
  rp+0x5f0 = 64           src_height
  rp+0x610 = 0            src_base    <-- the pixel buffer: MISSING
  rp+0x738 = 64           dst_img PWIDTH
  rp+0x758 = 64           dst_img PHEIGHT
  rp+0x6f8 / 0x718 = 0    (pipeline intermediate width/height, unused with no
                           crop/scale element)

So EXPORT is not failing to find the resource: it resolves the source resource
id and its 64x64 size correctly.  The only empty field is src_base, which is
loaded at 0x1B238 as `MOVE *A5(0x28),*A11(0x610)` -- i.e. element+0x28, which
we measured as 0 (evidence/element_pointer_timing.txt), and which no write
watchpoint ever saw being written.

CONCLUSION: the single missing datum is a pixel buffer base for the source
image (src_base / element+0x28).  The only request that would produce it is the
import (slot 19 PUT_TILE), which cannot enter because its typed lookup
requests class 3 and no addressable class-3 resource is producible.

Band array (*(res+44) = 0x003DC4B0) dumped immediately before EXPORT:

  +000: 00000000 00000000 00050029 40002005
  +010: 00000000 00050029 40002005 48000000
  +020: 00050029 40002005 48000000 48003DC5
  +030: 40002005 48000000 48003DC5 10003DC5
  +040: 48000000 48003DC5 10003DC5 00004007
  +050: 48003DC5 10003DC5 00004007 00000000
  +060: 10003DC5 00004007 00000000 18000000
  +070: 00004007 00000000 18000000 3FB90900

Note element+0x28 is NOT at band_array+0xd8 (that read yields 0x40 etc.); the
element pointer EXPORT uses is reached after the 0x1B230 `MOVE *A5(0x160)`
deref chain, so the earlier "element = *(res+44 + 0xd8)" shortcut was wrong.
The authoritative element pointer is the one EXPORT loads at 0x1B234
(EX_BAND a5=003DC4B0 elem@d8=003FDA10).

SIDE FINDING -- slot 47 is a dispatch trampoline, not a request:
  file 0x697B4 swaps the bytes of request words at bit offsets 0x10/0x18 then
  0x20/0x28 then 0x30/0x38, then does
    MOVE *A10(0x8),A11 (byte 1 = minor) ; SLL 5 ; ADDI 0xd3f90 ;
    MOVE *A11,A11 ; CALL A11
  i.e. it re-dispatches through the SAME table at 0xD3F90 after byte-swapping
  the first argument words.  It is the byte-swapped entry point for other
  requests, which is why a plain 3-word probe of minor 47 returned BadRequest.