chore: add resilience-test suite and remove individual test

[PeterSchafer]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

This PR moves existing separate tests into a single test suite for easier overview and maintenance.

Where should the reviewer start?

How should this be manually tested?

What's the product update that needs to be communicated to CLI users?

N/A

Risk assessment (Low | Medium | High)?

Low, changes tests only

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Global Side Effect 🟠 [major] Enabling isSecretsEnabled by default in featureFlagDefaults affects all acceptance tests in the repository that use the fakeServer. The existing comment in this file explicitly states that features should be enabled specifically by tests that target them. By making this a global default, other tests that do not expect or mock secrets-related API calls may fail when the CLI attempts to communicate with those endpoints. ['isSecretsEnabled', true], Brittle Test Scenario 🟡 [minor] In Scenario 4 (mid-execution-maintenance), the test sets the next status code to 200 for 4 requests without providing mock response bodies. CLI commands like test or monitor typically expect valid JSON from their initial API calls (e.g., for organization or user verification). If these calls return an empty 200 response, the CLI will fail with a JSON parsing error before reaching the maintenance failure state, causing the test to fail with an incorrect exit code. server.setNextStatusCode(200); server.setNextStatusCode(200); server.setNextStatusCode(200); server.setNextStatusCode(200);

📚 Repository Context Analyzed This review considered 5 relevant code sections from 4 files (average relevance: 1.00) CONTRIBUTING.md (2 segments, lines 1-218) package.json (lines 1-224) src/cli/main.ts (lines 1-236) cliv2/cmd/cliv2/main.go (lines 1-203)

[PeterSchafer]

Maybe we want to enable this only in the tests, to avoid doing this globally.