Found by running the endpoint against the live server. A request naming
`face_match.character_profiles` came back

    400: face_match was requested with no reference images

which is the opposite of the truth -- the caller HAD supplied references. The
cause was a bare `except Exception: pass` around the per-profile lookup, so a
misspelt name, a profile with no saved images, and a characters directory the
server resolves elsewhere all collapsed into that one message with nothing to
distinguish them. Establishing which it was took a long sequence of probes
against a running server: the field is declared (a bad type 422s with
loc body.face_match.character_profiles), the profile exists under both
candidate paths in the container, and resolve_character_profiles returns its
four images when called in-process -- so the swallowed exception was the only
thing standing between the symptom and the cause, and it is the defect.

Now each profile is resolved separately and its failure is named. When none
resolve the 400 lists them; when some do, the request proceeds (there ARE
references to match against) and the unusable ones are logged, because a
performer the caller believes is enrolled and is not would make a genuine face
read as "matches no consenting performer" for the wrong reason.

Verified live on the same server, all four checks against a real face:
nsfw 0.0003, one face at det_score 0.879, age 38.0 with the interval 30.0-46.0
and minor_probability 0.0, face_match similarity 1.0 matched against itself,
unmatched_faces 0, flagged false.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZnmWyKjWZerwsb27jZ