fix: project-only provider_access must not hide user-level providers

[ttmouse]

Summary

When the user config (~/.reasonix/config.toml) does not declare desktop.provider_access (implicit "allow all"), a project-level reasonix.toml that defines provider_access currently restricts the desktop model switcher to only those listed providers — hiding the user-level providers that exist outside the project-scoped access list.

Root cause: mergeTOMLProviderAccess merges provider_access as a union across config sources. When only the project config declares it (user config does not), the union equals the project's list alone. The user's default "allow all" is lost.

Fix: Track whether the user-level config explicitly declared provider_access. If only the project declares it (user did not), skip the restriction so all configured providers remain visible in the model switcher.

Verification

• TestMergeTOMLProviderAccessProjectOnlyDoesNotRestrictWhenUserUndefined — NEW: project-only restriction is correctly skipped
• TestMergeTOMLProviderAccessUserAndProjectMergeAsUnion — NEW: both user and project declare → union merge unchanged
• TestMergeTOMLProviderAccessNoDeclarations — NEW: neither declares → no restriction
• TestMergeTOMLProviderAccessUserDeclaresEmptyList — NEW: user declares [], project has list → project list takes effect (user explicitly opted into per-project control)
• TestModelsForTabKeepsUserProvidersWithProjectConfig — EXISTING PASS: user + project both declare → union unchanged
• go test ./internal/config/... — all pass
• go build ./... — all pass

Cache impact

Cache-impact: none — only a small logic change in config loading, no system prompt or provider changes
Cache-guard: existing config tests and desktop ModelsForTab tests cover the behavior
System-prompt-review: N/A

Related PRs

• PR Fix desktop model switcher provider scope merge / 修复桌面模型切换器配置作用域合并 #4492 (merged) — Added mergeTOMLProviderAccess with union logic, but left the gap when only the project declares the list.
• PR Fix desktop provider resolution across project configs #4516 (open) — Related provider access resolution changes in desktop/app.go, does not overlap with this fix.

---

🤖 This contribution was prepared with Reasonix (DeepSeek fork of Claude Code), no additional plugins installed.

[esengine]

Thanks — the diagnosis is right and the fix is the correct shape. An undeclared user-level provider_access means "allow all", and unioning it with a project-only declaration silently narrows the switcher to whatever the project happens to name. That's exactly the case #4492's union was meant to prevent and didn't.

I've landed it as #7395 rather than merging this branch: mergeTOMLProviderAccess was reworked after you opened this (statConfigPath, meta.IsDefined on the declaration, explicit-empty preservation), so the diff no longer applies. Your approach and the userDeclared guard carried over as-is, and you're credited as co-author on the commit.

One semantic call I made on top of your version: TestMergeTOMLProviderAccessPreservesExplicitEmpty now writes to the user config path. Explicit-empty ("I removed every provider") stays meaningful where it can be expressed — the user config — while a project's empty list no longer blanks the switcher, which follows from the same rule.

Closing this in favour of #7395. Thanks for the careful root-cause write-up — it made the port trivial.