feat(profiles): add ProfilesClient and RemoteConversation.switchLlm

[VascoSch92]

• A human has tested these changes.

Summary

• Add ProfilesClient mirroring the existing thin-client pattern (SettingsClient/SkillsClient): constructor takes { host, apiKey?, timeout? }, holds an HttpClient, and exposes close(). Methods cover the full /api/profiles surface: listProfiles, getProfile, saveProfile, deleteProfile, renameProfile, activateProfile. Path segments go through encodeURIComponent.
• Support the new X-Expose-Secrets header from agent-sdk #3161 via getProfile(name, { exposeSecrets }), where exposeSecrets is 'encrypted' | 'plaintext'. Header is omitted when not set, preserving the default nulled-api_key behavior.
• Add corresponding response/request types to models/api.ts (ProfileInfo, ProfileListResponse, ProfileDetailResponse, ProfileMutationResponse, ActivateProfileResponse, SaveProfileRequest, RenameProfileRequest, ExposeSecretsMode) and re-export from index.ts.
• Wire ProfilesClient into ConversationManager as manager.profiles, including close().
• Add RemoteConversation.switchLlm(llm) to fill a parity gap with the server's existing POST /api/conversations/{id}/switch_llm endpoint (sibling of the already-wired switchProfile).

Missing — integration tests

This PR ships unit tests only (mocked global.fetch). Integration coverage in src/__tests__/integration/ is not added here. Tracked in OpenHands/software-agent-sdk#4745:

• Profiles CRUD round-trip against a real agent-server — endpoints exist on main and can be tested now.
• switchLlm line in deterministic-api.integration.test.ts next to the existing switchProfile 404 check.
• X-Expose-Secrets: encrypted | plaintext end-to-end — blocked on feat(profiles): Add cipher encryption for LLM profile secrets software-agent-sdk#3161 merging.

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

[malhotra5]

Integration Feedback from agent-canvas

I've integrated this PR into the agent-canvas frontend (commit 195e9c3). The ProfilesClient and types work well! Here are a few observations:

Working Great ✅

• ProfilesClient methods map 1:1 with the agent-server API
• The GetProfileOptions.exposeSecrets approach is clean
• ProfileInfo, ProfileListResponse, ProfileDetailResponse, ProfileMutationResponse all match the backend responses

Type Compatibility Notes

1. SaveProfileRequest.llm is required - The SDK has llm: LLM as a required field. The previous local implementation had llm? (optional) to support a "snapshot current settings" mode. I verified the agent-canvas usage always provides llm, so this is fine for our use case. Just noting in case other consumers need the optional behavior.

2. ActivateProfileResponse.llm_applied - Good addition! The local implementation incorrectly expected model: string | null which wasn't actually returned by the backend.

3. LLM.base_url type - SDK uses base_url?: string while the local code sometimes passed base_url: null. Updated to use ...(baseUrlValue ? { base_url: baseUrlValue } : {}) spreading pattern to match the SDK type.

No Missing Features Found

The SDK covers all the ProfilesClient functionality needed by agent-canvas. The integration went smoothly!

---

This comment was created by an AI agent (OpenHands) on behalf of the user.

[malhotra5]

LGTM!