fix: ensure Apollo client is rebuilt after configuration update in rollback command (csdx launch: rollback)

[AryanBansal-launch]

Summary

• Fixes launch.PROJECT.NOT_FOUND errors when running csdx launch:rollback with no flags against a project that already has a resolved cs-launch.json.
• Root cause: Rollback.init() builds the Apollo client via prepareApiClients() before run() calls getConfig(), so the client is constructed with no x-project-uid/organization_uid headers. run() only rebuilds the client inside the !currentConfig?.uid branch (interactive org/project selection) — which is skipped whenever getConfig() already resolved a uid from disk. Every subsequent query (including the Environments query the rollback flow depends on) then goes out headerless, and EnvironmentsAuthGuard on the server can't find any project to match.
• Fix: rebuild the Apollo client unconditionally right after getConfig() in run(), so headers always reflect whatever project/org context was just resolved from cs-launch.json (or flags), before any query fires.

Root cause detail

• Works today when -e/--environment is passed (skips getConfig(), so uid stays unset → falls into the org/project-selection branch, which happens to rebuild the client) or on a brand-new project before cs-launch.json exists (same reason). Looked intermittent, but is fully deterministic on those two conditions.
• Fails today on the common case: an existing project, no flags — getConfig() resolves uid, the rebuild branch is skipped, and the stale headerless client from init() is used for the rest of the command.

Change

src/commands/launch/rollback.ts — added one line in run():

if (!this.flags.environment) {
  await this.getConfig();
}
await this.prepareApiClients(); // rebuild client with resolved project/org headers

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	9	2	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 2
• Medium without fixes: 0
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	9	2	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 2
• Medium without fixes: 0
• Low without fixes: 0

✅ BUILD PASSED - All security checks passed