Unify composable editor-card primitives across Settings

[mydmdm]

Context

Settings now reuses SettingSection, SettingRow, SettingControl, ApiKeyRow, and useDebouncedSave, but modules that combine selects, inputs, secrets, status feedback, and save actions still assemble their editor lifecycle independently. Utility Agent, Image Generation, Built-In model providers, and Ink OCR consequently duplicate loading/saving/error/status/action presentation and have previously diverged in spacing, empty-row rendering, and collapse behavior.

Follow-up to #253. This issue should improve the shared Settings component architecture without changing the persistence owner or product semantics of any setting.

Goal

Provide composable primitives for the repeated editor-card interaction structure while allowing each domain component to retain its own API/store and save timing.

Candidate shared surfaces include:

• In-card headers and consistent collapse behavior.
• Status rows that render only when content exists.
• Standard Save/Cancel action areas.
• Consistent loading, saving, saved, and error presentation with accessible roles.
• Reusable dirty-state or asynchronous-save state where semantics genuinely match.
• Continued reuse of ApiKeyRow for write-only credentials.

Prefer composition over a single highly configurable EditableSettingSection with many boolean props.

Save semantics that must remain distinct

• Utility Agent: immediate Profile save plus debounced functional-model save.
• Image Generation: immediate/debounced field saves plus explicit secret editing.
• Built-In model providers: provider switching, debounced fields, API keys, and OAuth flows.
• Ink OCR: transactional multi-field Save/Cancel form.

Acceptance criteria

• Shared visual and interaction primitives cover the repeated card header, status, and action patterns.
• Utility Agent, Image Generation, Built-In provider/model settings, and Ink OCR adopt the applicable primitives.
• Existing save timing, API ownership, credential handling, and error behavior remain unchanged.
• Empty status/action containers are not emitted.
• Spacing, keyboard behavior, loading/saving/error feedback, and accessible status roles are consistent.
• Focused regression tests cover each migrated Settings surface.
• The relevant architecture documentation describes the resulting component boundary.

Non-goals

• Unifying backend endpoints or stores.
• Changing which capabilities are available to external Agents.
• Changing Utility Agent or conversational-Agent routing.
• Redesigning the Settings information architecture established by Follow-up: Agent lifecycle, unified Settings, Windows discovery, and multi-Agentlet enrollment #253.