### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When an Access Group is assigned **directly to a Virtual Key** (via the UI, resulting in a populated `access_group_ids` field on the key), the model authorization check **ignores** `key.access_group_ids` entirely and falls back to the team's `models` list instead.

This causes a `403` error even though `access_group_ids` is correctly stored on the key and the access group contains the requested model.

**Expected behavior:** The model authorization check should resolve the full permission chain: ``` key.access_group_ids → access_group.models → allowed models ``` When `key.access_group_ids` is set, the models in those access groups should be merged into the allowed models for that key — independent of the team's model list.

**Actual behavior:** The authorization check only evaluates `team.models`. The key's `access_group_ids` field is stored correctly but never consulted during model access validation. The team restriction (`no-default-models`) takes precedence and blocks the request.

**Workaround:** Assign the Access Group to the **Team** ins…