fix: ensure config.yaml exists and is populated when accessed

[RomneyDa]

Summary

• Gear icon (open config profile) now creates config.yaml with defaults if the file is missing, matching the behavior on startup
• Empty config.yaml is detected and populated with the default config instead of causing a parse error

Test plan

• Delete ~/.continue/config.yaml, click the gear icon in the GUI — file should be created with defaults and opened
• Create an empty ~/.continue/config.yaml, reload — should be populated with default config
• Normal startup with existing config.yaml — no behavior change

---

Summary by cubic

Create and populate config.yaml with defaults when opening the config profile and when the file exists but is empty. This prevents parse errors and aligns behavior with startup.

• Bug Fixes
  • getConfigYamlPath() now writes defaults if config.yaml is missing or empty, with a simplified existence check for readability.
  • Opening a local config profile (gear icon) calls getConfigYamlPath() first to ensure the file exists with defaults.

^{Written for commit 2008894. Summary will update on new commits.}

[continue]

Docs Review

No documentation updates needed for this PR.

Reason: This is a bug fix that improves the robustness of existing documented behavior. The docs already state that Continue "generates a config.yaml with sensible defaults" (in Understanding Configs). This PR simply ensures that behavior works correctly in additional edge cases (clicking the gear icon, empty config files) without changing the user-facing contract.

The implementation details of when and how the default config is created are internal concerns that don't need to be documented.

[continue]

Test Coverage Review

This PR introduces bug fixes to getConfigYamlPath() that would benefit from regression tests:

Suggested Test Cases for getConfigYamlPath()

1. New bug fix scenario: When config.yaml exists but is empty → should populate with default config
2. Existing behavior preserved: When neither config.yaml nor config.json exist → should create config.yaml with defaults
3. Existing behavior preserved: When config.yaml exists with content → should not overwrite it
4. Existing behavior preserved: When config.json exists but config.yaml doesn't → should not create config.yaml

Why Tests Are Recommended

Per the project's test expectations for bug fixes: "If a PR fixes a bug, there should be a regression test that reproduces the original bug condition and verifies the fix resolves it."

Currently, there are no existing tests for getConfigYamlPath() in the codebase. Adding tests would prevent regressions of this empty-file handling logic.

Test Location

Tests could be added to a new core/util/paths.vitest.ts file or within the existing core/config/ test files, using the established Vitest pattern.

[cubic-dev-ai]

No issues found across 2 files