Please address the comments from this code review:

## Overall Comments
- The `axios.get(releaseUrl)` response is now unused; if the only purpose is to fail fast on an invalid tag, consider either removing the call entirely and relying on the GCS request to surface errors, or adding a short comment to clarify that the call is intentionally kept just for tag validation.
- When parsing the `.sha256` file, using a generic `/[a-f0-9]{64}/i` regex may accidentally match unrelated hashes if the format ever changes; you might want to split on whitespace and take the first token (or anchor the regex to the start of the line) to make the checksum extraction more robust to file contents.

## Individual Comments

### Comment 1
<location> `src/core/updater.ts:49-54` </location>
<code_context>
-            expectedChecksum = match[1];
-        } else {
-            logger.warn(`Could not extract checksum for ${ASSET_NAME} from release notes.`);
+        // Fetch checksum from deterministic GCS sidecar file
+        const checksumUrl = `${downloadUrl}.sha256`;
+        const checksumResponse = await axios.get(checksumUrl, { responseType: 'text' });
+        const checksumText = String(checksumResponse.data).trim();
+        const checksumMatch = checksumText.match(/[a-f0-9]{64}/i);
+        if (!checksumMatch) {
+            throw new Error(`Checksum file did not contain a valid SHA256 hash (${checksumUrl})`);
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Tighten checksum regex to reduce risk of picking up an unintended hash when the file has additional content.

`/[a-f0-9]{64}/i` will match the first 64‑char hex run anywhere in the file. If the sidecar ever includes multiple hashes or extra content (e.g. multiple files, comments, or a header with a hash‑like token), we could verify against the wrong value. Prefer anchoring to the start of a line and capturing only the first token, e.g. `/^([a-f0-9]{64})\b/m`, which also supports `<hash>  filename` formats.

```suggestion
        const checksumText = String(checksumResponse.data).trim();
        // Extract a single SHA256 hash from the start of a line (supports "<hash>  filename" formats)
        const checksumMatch = checksumText.match(/^([a-f0-9]{64})\b/im);
        if (!checksumMatch) {
            throw new Error(`Checksum file did not contain a valid SHA256 hash (${checksumUrl})`);
        }
        expectedChecksum = checksumMatch[1];
```
</issue_to_address>

### Comment 2
<location> `src/core/updater.ts:41` </location>
<code_context>
     try {
         const releaseUrl = `https://api.github.com/repos/${GITHUB_REPO}/releases/tags/${version}`;
-        const response = await axios.get(releaseUrl);
+        await axios.get(releaseUrl);

         // Google Cloud SQL Proxy v2 binaries are hosted on GCS
</code_context>

<issue_to_address>
**suggestion (performance):** Re-evaluate the need for the GitHub release fetch now that the checksum is sourced from GCS only.

This call no longer uses the response and now just adds an extra network round trip per download. If it’s only meant to validate that the GitHub tag exists, consider making that explicit (e.g., distinct handling/logging for "unknown version" vs generic network errors). If that validation isn’t needed anymore, removing the call would simplify the flow and reduce latency.

Suggested implementation:

```typescript
    try {
        // Google Cloud SQL Proxy v2 binaries are hosted on GCS
        downloadUrl = `https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/${version}/${ASSET_NAME}`;

```

1. Remove the now-unused `axios` import at the top of `src/core/updater.ts` (e.g., `import axios from 'axios';`) if present.
2. If there was any error handling that specifically depended on the GitHub call (e.g., distinguishing 404 on the GitHub tag), that logic can now be removed or updated to rely solely on GCS-related errors.
</issue_to_address>