Fix/provider onboarding flow

[brandomr]

Summary

Fixes the brand-new-user onboarding flow: configure a provider → enter an API key → use the agent. Four independent commits, each one fix:

1. config: don't let one broken model module break the provider config UI. get_providers() imported every archytas model module; a single failing import (e.g. an upstream dependency mismatch) bubbled up through the config-schema builder and blanked the entire provider-configuration dialog (no API-key field at all). Failing modules are now skipped with a warning, discovery is cached so broken imports aren't re-attempted/re-logged each call, and ConfigController.map_type no longer crashes on non-class type origins (e.g. typing.Literal[...]) or swallows errors silently.

2. ui: provider-config form no longer overlaps the dialog buttons. The form was styled via a dead id (#config-panel-provider, left with a debug background-color: blue), so it was never placed in its grid cell and its fields overflowed onto the Reset/Cancel/Save row. Pointed the rule at the real element and let it scroll within the cell.

3. ui: re-run the originating query after configuring credentials. The query cell only tagged msg.cell for the "Request interrupted" case, so on anllm_auth_failure the model-config dialog had no cell to re-run — the user's prompt was silently dropped and had to be re-typed. Now the originating cell is tagged and re-runs once a provider is configured.

4. kernel: sync chat-history model on live model change. set_agent_model swapped the agent's model but not the chat history's, leaving the chat-history panel (which reads model metadata and token budgets from the chat history) stuck on the keyless default. Routes the change through agent.set_model().

Dependency

We call Agent.set_model(), and the "key takes effect immediately" behavior relies on the env-precedence fix — both from jataware/archytas#83. Merge + release that first, then bump the archytas>= pin in this repo to that release.

Tests

• tests/test_get_providers_resilience.py — provider discovery tolerates failing imports and returns a fresh (non-shared) mapping.

Manual verification

Full blank-slate run (no config file): first message → provider-config modal (no overflow) → select provider, paste key → Save → key takes immediately → original prompt auto-runs → chat-history panel populates. Verified end-to-end for openai; non-openai providers were verified to bind the configured key directly.

[mattprintz]

The first popup when attempting a first query works great. It just finished running the query and is great.

Including for visibility a few things I noticed, that seem to be unrelated to the work you did. Not sure how/when we want to address them, so just listing them here

1. You can break things when copy/pasting in a way that isn't obvious. I.e. if you put in the correct key but a bad model name, the form goes away but you just get failed queries and no errors except for in the console.

• E.g. anthropic.NotFoundError: Error code: 404 - {'type': 'error', 'error': {'type': 'not_found_error', 'message': 'model: claude-4-6'}
• Probably should expose all errors communicating with the model, and open the panel back up if you get a 404 and not just a Forbidden.

2. The flow with setting the model is so smooth, it makes changing through the side panel feel extremely clunky with the modal and restarting the kernel and refreshing things.
3. The default models are SUPER old at this point and could do with a refresh.
4. There's just enough lag when loading the configuration popup (at least for me) that it makes one wonder if there is something wrong. Having some sort of loading indicator would be awesome (or just make it slightly faster).

• I suspect the slowness is because it's importing all the archytas models and related langchain models which are notoriously slow to import.

[mattprintz]

Looks good.

I left some things I noticed in the comment, but they aren't blockers for this I think.

[brandomr]

These are all very good points. I noticed the lag as well on loading. I want to think a bit about new user onboarding in general. The modal exposes things most users wouldn't even know what to do with (I think?) so we may want to streamline it. We may also need some instruction on how to actually get an API key. I'll think on it more.