fix: parse combo models correctly when returned as objects

[herjarsa]

The OmniRoute API /api/combos recent update returns an array of objects for underlying models instead of an array of strings. This caused opencode-omniroute-auth to crash when calling modelId.trim() in splitModelId. This PR adds a map to properly extract the model or id property if it is returned as an object. Confirmed to resolve the issue with standard combos like Combo-FIX recovering access to the full model index.

[gemini-code-assist]

Code Review

This pull request modifies the resolveUnderlyingModels function to correctly extract model identifiers from the models array, which may now contain objects. Feedback was provided regarding potential runtime errors if the array contains null values or objects without the expected properties, recommending a safer mapping implementation and an update to the OmniRouteCombo interface for better type safety.

[Alph4d0g]

Thanks @herjarsa for opening this PR and catching the API change so quickly! The crash from .trim() on object-shaped model entries was a real issue, and your fix points exactly at the right spot.

I really appreciate you taking the time to debug this and confirm it resolves the problem with standard combos like Combo-FIX.

I've pushed two small atomic commits on top of your branch to harden the implementation before we merge:

1. types: update OmniRouteCombo.models to accept objects from API — Updates the interface so models reflects the new API shape (Array<string | { model?: string; id?: string }>) instead of the old string[].

2. fix: harden resolveUnderlyingModels against null and missing properties — Replaces the any assertion with runtime type narrowing, handles null/undefined entries safely, and filters out unresolvable items with a warning rather than letting undefined propagate downstream and crash later.

The logic is still fully backward-compatible with string arrays, and the build passes cleanly.