ADR-002: resolve credential brokering for rein-openweights (Option B)

rein-openweights acquires its OpenRouter credential directly
(OpenBao/ops-warden), consistent with rein-aharness's existing
credential-holder principle — glas-harness does not broker
LLM-provider credentials. Confirmed llm-connect itself never brokers
credentials either (resolve_api_key() only reads an
already-materialized key from explicit/env/file), so routing through
llm-connect vs. a leaner wrapper doesn't change this. Composable reins
as middleware (monitoring/eval/optimization) is recorded as a separate,
deliberately deferred question in the same ADR — one candidate
capability isn't evidence of a recurring pattern yet.

GLAS-WP-0001-T06 done; T05 (bootstrap rein-openweights) unblocked.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/adr/ADR-001-rein-harness-family.md

@@ -88,6 +88,7 @@ through an equivalent agentic tool-use loop.
   (kaizen-agentic, activity-core), or does only `rein-aharness` depend on
   those while `rein-openweights` is triggered differently (e.g. directly
   by glas-harness channels)?
-- Where does credential brokering for `rein-openweights`'s OpenRouter/
-  llm-connect calls live — glas-harness (per the sandbox-consumption
-  pattern) or the rein itself?
+- ~~Where does credential brokering for `rein-openweights`'s OpenRouter/
+  llm-connect calls live~~ — resolved in
+  `docs/adr/ADR-002-credential-brokering-and-composable-reins.md`: the
+  rein itself (Option B), not glas-harness.