Description

Two related papercuts in the Settings profile sidebar (shared by LLM / Embedding / Search):

1. Renaming a profile was undiscoverable. The only way to rename was a double-click on the row — with no visible affordance, users couldn't find it.
2. The profile name didn't follow its provider. A profile is created already named after its provider (e.g. "Brave"), but switching the provider afterwards left the old name — so a profile showing "Brave" could actually be pointing at DuckDuckGo, which is confusing.

This PR:

1. Adds an always-visible pencil button in each profile row, styled like the existing icon buttons (muted, brightening on hover; keyboard-reachable). It opens the same inline rename, reusing the existing Rename profile label. Double-click still works.
2. Keeps an un-customized name in sync with the provider: when the provider changes, a name that is empty or still equal to the previous provider's label is updated to the new provider; a name the user typed by hand is never overwritten. The check is stateless — no new persisted field (nextProfileName in web/components/settings/profile-naming.ts).

No new i18n strings (reuses the existing Rename profile key). LLM / Embedding / Search all benefit, since they share the sidebar and the provider→name logic.

⚠️ Depends on #570 — please merge that one first. Both PRs edit web/components/settings/ServiceConfigEditor.tsx; this branch is cut from dev and builds on its own, but it's intended to land after #570 to avoid a merge conflict (see Note on stacking below).

💬 Open to discussion

Happy to adjust before merging if you see it differently — e.g.:

• Pencil always-visible vs. hover-only — I went always-visible (dimmed) for discoverability and touch; can switch to reveal-on-hover if you prefer a cleaner row.
• Auto-name heuristic — it's intentionally stateless (name follows provider until you type a custom name). If you'd rather have an explicit "name locked" flag persisted in the catalog, I can do that instead.

Related Issues

• Depends on fix: show only provider-relevant fields in Search settings #570 (Search field visibility) — merge after it.

No existing issue for this change — searched open/closed issues and PRs; none cover it. Happy to open one if preferred.

Module(s) Affected

• agents
• api
• config
• core
• knowledge
• logging
• services
• tools
• utils
• web (Frontend)
• docs (Documentation)
• scripts
• tests
• Other: ...

Checklist

• I have read and followed the contribution guidelines.
• My code follows the project's coding standards.
• I have run pre-commit run on the changed files — all hooks pass.
• I have added relevant tests for my changes.
• I have updated the documentation (if necessary).
• My changes do not introduce any new security vulnerabilities.

Screenshots

Rename affordance — a pencil button is now visible in each profile row. The name also tracks the provider until customized (here it reads DuckDuckGo because the profile hasn't been renamed):

Inline rename — clicking the pencil (or double-click) opens the rename field in place:

A profile you've manually renamed keeps its name when you change providers — only auto-named profiles follow.

Additional Notes

Note on stacking (#570)
This touches web/components/settings/ServiceConfigEditor.tsx, same as #570 (Search field visibility). The changes are in different regions (sidebar/rename vs. provider field rendering), so the only collision is an adjacent import line. To keep history clean I'd merge #570 first, then rebase this branch onto dev (trivial) before merging.

Verification

• tsc --noEmit (full project) — clean
• node --test — full web suite green (137 tests), incl. new tests/profile-naming.test.ts (6 cases: auto name tracks provider, empty name filled, custom name preserved, empty new label no-op, whitespace-insensitive, same-provider no-op)
• eslint — 0 errors
• Rebuilt the Docker image and confirmed the change is bundled and the app boots healthy.