[ottonomy]

Closes #50

Stacked on #70 — review and merge that first (or merge the stack together).

Departures

None. The handler now returns the recognised credentialSubject entry as the
match's entity, mapped the way the OIDF handler maps its metadata, and the
five places that said vc-recognition matches carry no entity have been
rewritten.

Decisions not in the issue

• subjectContainsDid became findSubjectEntry, returning the matching entry
  rather than a boolean, and the array and single-object subject shapes are now
  handled by one find over a one-element array instead of two branches. The
  behaviour for a missing or non-object subject is unchanged.
• The entity mapping lives in a local entityFromEntry, mirroring the name and
  the doc-comment shape the OIDF and dcc-legacy handlers already use, rather
  than being shared between handlers: the three mappings read different source
  shapes and nothing is deduplicated by pulling them together.
• Two existing tests asserted the whole found result with toEqual, so they
  now carry the expected entity too. New tests cover the string url/logo
  case alongside an unmapped image, an entry with no name, an entry whose
  name, url and logo are a language map / object / array, and a second
  lookup served from the handler's cache.
• New assertions are written against the whole handler result rather than
  result.entity, as the OIDF spec does: HandlerResult is a union whose
  not-found member has no entity, so reading the property directly would
  add a type error to the dev type-check.
• The architecture doc's file-tree line for vc-recognition-handler.ts was left
  alone; the OIDF line next to it does not mention entities either, and the
  prose section further down carries the description.

Agent-Run: b8b4ceec-5ec2-4bd8-8aa4-f7b4617ddde8