fix(958): base64-encode binary map data in /api/protmap/

[claude-im]

Fixes #958.

Problem

/api/protmap/ returns 500 in production. SiteObservation.event_file is a binary electron-density map, but ProtMapInfoSerializer.get_map_data read it as UTF-8 text:

return open(obj.event_file.path, encoding='utf-8').read()

On real map data this raises UnicodeDecodeError on the first non-UTF-8 byte (the production traceback failed on 0x9c). The field was historically a text map_info; when it became the binary event_file the text read was never updated (an in-code TODO already flagged "it's binary and not read").

Fix

Read the file as bytes and return it base64-encoded, so the JSON response is valid and lossless; clients base64-decode to recover the raw map. Also switched to a context manager so the file handle is always closed.

if obj.event_file:
    with open(obj.event_file.path, "rb") as map_file:
        return base64.b64encode(map_file.read()).decode("ascii")
else:
    return None

⚠️ API contract change (frontend note)

map_data now contains base64, not raw text. This is unavoidable for binary content in a JSON field — and the endpoint currently always 500s on real maps, so there is no working behaviour to preserve. Any consumer of /api/protmap/ must base64-decode map_data. The sibling text endpoints (/api/protpdb/, /api/protpdbbound/) are unchanged — PDB files are ASCII text and read fine.

Testing

New regression test viewer/tests/test_protmap_serialization.py (written first, TDD):

• confirms binary content including 0x9c is base64-encoded and round-trips (it reproduced the exact production UnicodeDecodeError before the fix);
• confirms the no-event_file case still returns None.

Full suite: 102 passed, 1 skipped; pre-commit (isort/black/mypy/pylint) clean.

🤖 Generated with Claude Code