Add an adapter config for a second Jev-compatible endpoint

[TMHSDigital]

Good first issue. This is the config-not-code path that CONTRIBUTING
describes, exercised for real. No new module, no new transport.

The task

Add and verify an adapter configuration for a second Jev-compatible endpoint,
so the claim that "anything serving the Jev wire format is a base_url for
typesafe_wire" is demonstrated rather than asserted.

CONTRIBUTING says a new vendor is a config entry. Right now there is exactly
one endpoint in use, so that claim has never been tested against a second one.

Candidates

Open decision models that serve this wire format, any of which should run on
the unchanged adapter:

• A self-hosted compatible server in front of an open checkpoint.
• Mapika/decider, which serves the same
  typed question shape.
• Bespoke Nimble, which serves the
  wire format directly.

Any one of them is enough. Picking whichever is easiest to stand up is the
right call.

What done looks like

• A run completes end to end against the second endpoint through
  typesafe_wire with only a base_url and a model string, and no change to
  any adapter module.
• The artifact records the endpoint, so the result is traceable to what
  answered it.
• If something small blocks it, that is a bug in the adapter worth fixing and
  worth reporting here. CONTRIBUTING says so explicitly: a near-miss is not a
  reason for a fourth transport.
• A short note in the docs listing at least one verified non-default endpoint,
  so the next person has a worked example rather than a promise.

Why it is a good first issue

It needs no knowledge of the calibration mathematics. It touches configuration
and documentation, and the interesting part is whether the abstraction holds,
which you find out by trying it.