Please address the comments from this code review:

## Overall Comments
- The new `getLatestPrerelease` helper picks the first prerelease returned by the `/releases` endpoint, which is not guaranteed to be the latest; consider explicitly sorting by `published_at` or `created_at` and selecting the newest non-draft prerelease to make the behavior predictable.
- In `upgrade.ts`, multiple `writeConfig` calls (`--unpin`, then possibly `--pin` or `--channel`) can lead to partial updates depending on how `writeConfig` merges state; it would be more robust to build a single combined config patch and persist it with one `writeConfig` call.

## Individual Comments

### Comment 1
<location> `src/commands/upgrade.ts:41-43` </location>
<code_context>
         try {
             const currentVersion = process.env.CLOUDSQLCTL_VERSION || '0.0.0';
+            const config = await readConfig();
+            const channel = (options.channel || config.updateChannel || 'stable') as 'stable' | 'beta';
+
+            if (channel !== 'stable' && channel !== 'beta') {
+                throw new Error(`Invalid channel '${channel}'. Use 'stable' or 'beta'.`);
+            }
</code_context>

<issue_to_address>
**suggestion:** Invalid `updateChannel` values in existing config cause the command to error instead of gracefully defaulting.

With this change, any unexpected value in `config.updateChannel` will cause every `upgrade` run to fail until the config is manually fixed, making the command fragile to older configs or corruption. Consider treating invalid values as a warning and defaulting to `'stable'` (and optionally persisting that change), e.g. compute a `rawChannel`, validate it, and on invalid values log a warning and fall back to `'stable'` instead of throwing.

Suggested implementation:

```typescript
        try {
            const currentVersion = process.env.CLOUDSQLCTL_VERSION || '0.0.0';
            const config = await readConfig();

            // Determine raw channel from CLI options or config without defaulting yet
            const rawChannel = options.channel ?? config.updateChannel;
            let channel: 'stable' | 'beta' = 'stable';

            if (rawChannel === 'stable' || rawChannel === 'beta') {
                channel = rawChannel;
            } else if (rawChannel !== undefined) {
                // Gracefully handle invalid values by warning and falling back to 'stable'
                console.warn(
                    `Warning: invalid update channel '${rawChannel}' in configuration. Falling back to 'stable'.`,
                );
            }

            if (options.unpin) {

```

If your project uses a structured logger instead of `console.warn`, replace the `console.warn` call with the appropriate logging utility (e.g. `logger.warn(...)`) and ensure any required imports are added at the top of `src/commands/upgrade.ts`.
</issue_to_address>

### Comment 2
<location> `src/commands/upgrade.ts:47-53` </location>
<code_context>
+                throw new Error(`Invalid channel '${channel}'. Use 'stable' or 'beta'.`);
+            }
+
+            if (options.unpin) {
+                await writeConfig({ pinnedVersion: undefined });
+            }
+
+            if (options.pin) {
+                await writeConfig({ pinnedVersion: options.pin, updateChannel: channel });
+            } else if (options.channel) {
+                await writeConfig({ updateChannel: channel });
+            }
</code_context>

<issue_to_address>
**suggestion:** Multiple sequential `writeConfig` calls could be consolidated into a single update for consistency and to avoid potential race conditions.

In the current flow, a single invocation (e.g. `--unpin` + `--channel`) can trigger two `writeConfig` calls. Consider accumulating the changes in a `configUpdate` object and calling `writeConfig` once. This keeps the behavior easier to reason about and reduces the risk of subtle race issues if `writeConfig` becomes more complex or asynchronous in the future.
</issue_to_address>

### Comment 3
<location> `docs/commands.md:326` </location>
<code_context>
+                       "auto")
+  --dir <path>         Download directory (default:
+                       "<USER_HOME>\\AppData\\Local\\CloudSQLCTL\\downloads\\updates")
+  --force              Force update even if version is same or older
+  --no-silent          Run installer in interactive mode (installer only)
+  --no-elevate         Do not attempt to elevate privileges (installer only)
</code_context>

<issue_to_address>
**nitpick (typo):** Consider adding articles for smoother grammar in the `--force` description.

For example: `Force update even if the version is the same or older` makes the sentence grammatically complete while keeping the intended meaning.

```suggestion
  --force              Force update even if the version is the same or older
```
</issue_to_address>