fix(ai): read the assistant model from the account data

[paultranvan]

Problem

Changing an AI assistant's model has no effect unless the API key is retyped at the same time: the conversation keeps running on the model the assistant was created with.

The provider account stores the model in auth.login and the API key in auth.password, and the stack bundles the two into auth.credentials_encrypted (encryptMap, model/account/credentials.go). That blob is only rebuilt when a password is present in the incoming document, so editing only the model leaves it encrypting the previous model — and buildLLMOverride read the blob in preference to the plain fields.

The model therefore exists in two places that drift apart, and the stale one won.

Fix

Rather than picking the fresher of the two copies, stop duplicating the model.

The model is configuration, not a credential, so it moves to data.model, next to the data.baseUrl that was already there — out of reach of the encryptor, which only ever touches auth. The two concerns are split into llmModel and llmAPIKey:

	before	after
model	auth.login, duplicated into the encrypted blob	data.model
API key	auth.password → encrypted blob	unchanged
base URL	data.baseUrl	unchanged

auth now holds what must be encrypted, data holds the rest, and the resulting triplet maps one-to-one onto OpenRAG's llm_override = {model, api_key, base_url}.

The encrypted blob is deliberately never consulted for the model: its copy is precisely the one that goes stale, and resurrecting it would turn a missing field into a silently wrong value.

Impact

No migration required. Accounts written before the move still carry the model in auth.login, which is never encrypted and therefore always up to date, so llmModel falls back to it. Every existing assistant is fixed as soon as this is deployed, and the stack can ship independently of the client.

The fallback is marked as transitional: it can be dropped once cozy-client writes data.model and existing accounts have been rewritten.

Follow-up on the client side

cozy-client must write data.model and stop writing auth.login. Note the ordering constraint: an account's display label is derived from auth[account.identifier], falling back to auth.login (cozy-harvest-lib getLabel, cozy-doctypes Account.getAccountName). Once auth.login is gone, that falls through to account._id, so the client change that sets identifier: 'accountName' and auth.accountName must land first.

That naming is a separate symptom of the same root cause — with the model sitting in auth.login, ComputeName labelled these accounts gemini-2.5-flash instead of Google — and is handled in its own client-side PR.

Tests

TestLLMModel and TestLLMAPIKey cover the data/login precedence, the legacy fallback, the encrypted-key paths, and one case that explicitly locks in that a stale encrypted model is never resurrected.

[shepilov]

Does it make sense not to store a model in auth.login at all?

[shepilov]

And how we update the model in the account info?

[paultranvan]

Does it make sense not to store a model in auth.login at all?

actually yes, it makes more sense. I change it, so it is now on account.data.model, at the same level than account.data.baseUrl

[paultranvan]

And how we update the model in the account info?

On user-side, we can edit an external LLM provider account with a new model name (gpt-4, opus5, mistral-large, ...)