Epic: Fix Intrinsic Adapter Lifecycle & Consistency in Mellea

[jakelorocco]

Resolve systemic issues with how intrinsic adapters are loaded, invoked, and configured across backends. We should finalize a design for the below points and then create issues for that finalized implementation.

Initial implementation of EmbeddedIntrinsicAdapters in: #881
Initial removal of OpenAI adapters: #543

1. Adapter Loading & Unloading
   a. Clean up divergent control flow between EmbeddedAdapters and regular Intrinsics loading.
   b. Fix bug where obtain_lora is always called during call_intrinsic when embedded_adapters=False, which masks the real error from users and conflicts with different loading methods.
   c. Address that adapter loading/unloading is both backend-specific and adapter-type-specific — design a coherent abstraction for this.

2. Model Option Handling
   a. Fix intrinsic rewriters overwriting model options unconditionally.
   b. Decide and document how intrinsics should interact with model options.
   c. There's a larger question of hierarchy with model options as well. Model options can technically be defined in all the following places: hf base model defaults in generation_config.json, adapter defaults in generation_config.json, io.yaml defaults, io.yaml values specified in the Mellea intrinsic, mellea model options.

3. Naming Consistency
   a. Resolve whether adapter name must equal adapter.intrinsic_name or can differ (open issue).
   b. Standardize usage of "adapter name", "intrinsic name", and "qualified name" across the codebase.
   c. refactor(intrinsics): decouple capability registry from catalog entry names (Epic #929 Phase 0) #1186 Decouple the capability registry from catalog entry names — Phase 0 follow-up. The role→capability rename lands in feat(intrinsics): introduce Adapter/Identity/IOContract/WeightsBinding scaffolding (Epic #929 Phase 0) #1134 (PR feat(intrinsics): introduce Adapter/Identity/IOContract/WeightsBinding scaffolding (Epic #929 Phase 0) #1158); the catalog-side decoupling is next in sequence once fix(intrinsics): pin catalogue entries to HF revision SHAs + deduplicate requirement_check (#1135) #1157 (fix(intrinsics): pin catalogue entries to HF revision SHAs + deduplicate requirement_check entries (Epic #929 Phase 0) #1135) and feat(intrinsics): introduce Adapter/Identity/IOContract/WeightsBinding scaffolding (Epic #929 Phase 0) #1158 (feat(intrinsics): introduce Adapter/Identity/IOContract/WeightsBinding scaffolding (Epic #929 Phase 0) #1134) merge.

4. Output Parsing & Generic Intrinsic Contracts
   a. Address the problem where top-level call_intrinsics helpers assume a single output structure (e.g., result_json["answerability"] vs result_json["answerability_likelihood"]). We likely need to work with the Intrinsic team here to set common assumptions.
   b. Determine whether all adapters of a given type must conform to a standard output schema (e.g., a single output field, required keys) or whether parsing should be adapter-specific.
   c. This also encompasses "versioning" of intrinsics. The "same" intrinsic may be updated / changed to have a different expected output format and our top-level call_intrinsic functions only allow one version.

5. OpenAI Backend Support
   a. Add OpenAIAdapters back — requires discussion on the logic for pulling/registering these. EmbeddedIntrinsicAdapters should technically inherit from these.

6. Cleanup
   a. Remove or repurpose the catalog. We shouldn't mandate all intrinsics be a part of the known catalog.

[jakelorocco]

7. Additionally, we found several issues due to hard-coded requirement_check adapters in our code for automatically utilizing requirement check adapters when present for requirements. The new design should account for this (and perhaps allow the intrinsic that ultimately gets used to be configurable). The changes from this PR should include all the spots that are necessary to evaluate these hard-coded values: https://github.com/generative-computing/mellea/pull/1008/changes.

[planetf1]

Note from PR #1028 review: PR #1028 (normalize intrinsics interfaces) adds a new context-mutation path in the guardian intrinsics — both factuality_detection and factuality_correction now rewind and re-attach documents to the last assistant message before calling call_intrinsic. This path will need to be accounted for in the lifecycle refactor here; specifically, the rewind logic operates on context.previous_node and re-wraps the last turn, which could interact with any changes to how turns are structured during adapter loading/unloading.

[planetf1]

Aiming to summarise / explain the current setup, issues, and what we want to achieve

Early version -> https://github.com/planetf1/mellea/blob/docs/issue-929-adapter-design-proposal/docs/dev/issue-929-adapter-design-proposal.md -- still checking for correctness. Hoping to get this right up-front, then the implementation should be easy ;-)

Ok to check in as a PR if useful