GET and POST /get_setid return HTTP 500 when conflations are invalid or a set has no CURIEs #47

generate_setid() in src/nodenorm/handlers/set_identifiers.py has two early returns that return the SetIDResponse dataclass itself, while its normal path returns dataclasses.asdict(response):

• an unknown conflation sets response.error and returns response (line 101 on main);
• a set whose CURIEs normalize to nothing returns response (line 143 on main). This happens when a POST set has "curies": [] or no curies key, since curies defaults to [].

Tornado can't write a dataclass, so instead of the SetIDResponse with error filled in that the OpenAPI document promises, the caller gets HTTP 500:

• GET /get_setid?curie=MESH:D014867&conflation=Foo → 500 (self.finish() rejects a non-dict object)
• POST /get_setid with [{"curies": ["MESH:D014867"], "conflations": ["Foo"]}] → 500 (the dataclass can't be JSON-encoded)

Both were reproduced by mounting SetIdentifierHandler alone on main. The invalid-conflation path returns before any Elasticsearch lookup, so it needs no host. The empty-CURIEs path was found by reading the code and wasn't run.

Suggested fix: return dataclasses.asdict(response) on every path, or have generate_setid() always return the dataclass and convert it in the handlers. Then add a host-free test for each early return. TestSetIdentifierPost in tests/test_openapi.py shows how to mount the handler without Elasticsearch.

Separately, the OpenAPI document gives SetIDQuery.curies minItems: 1. The handler could answer an empty set with 400 instead of a SetIDResponse, but that's a choice about the API, not part of this bug.

Found in the review of #42.