fix(sagemaker): improve error handling when the Space SSH host check fails

[bhavya2109sharma]

Problem

When attempting to connect to a SageMaker Space, if the user's SSH config had issues (like the old User '%r' directive),
users would see an unhelpful error :

ssh check against host failed: 255

This happened because:

1. SSH validation ran before checking if the config was outdated
2. The outdated config caused SSH validation to fail
3. Users had no opportunity to fix the issue before seeing the error

Solution

Implemented a proactive SSH config validation that checks for outdated config before running SSH validation
Prompts users to update outdated config automatically
Provides helpful error messages with line numbers for external errors
Validates before showing progress dialogs (better UX)

Changes Made

New Files Created

1. packages/core/src/awsService/sagemaker/sshConfig.ts : Created SageMakerSshConfig class that extends the base SshConfig class with SageMaker specific SSH logic.
2. packages/core/src/test/awsService/sagemaker/sshConfig.test.ts- test suite

Modified

1. packages/core/src/awsService/sagemaker/model.ts: Removed ensureValid() from prepareDevEnvConnection() and added comment explaining validation happens in commands.ts

2. packages/core/src/awsService/sagemaker/commands.ts : Added validateSshConfig() which will validate before showing progress dialogs so that users can fix issues before any connection attempt starts

Testing

1. SSH Config Exists, No sm_* Section
2. Happy path : Up-to-Date sm_* Section
3. Outdated or has error sm_* Section (e.g., has User '%r')
4. Syntax Error in SSH Config (Outside sm_* Section)

• All the testing is done for SMUS and SM-AI (with deeplink)
• Tested changes for Platforms : Mac, Win, Linux

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[vpbhargav]

I think worth testing this change in Widows/Mac and Linux if possible. Hard to validate regex validations and some of these platforms have casing, newline peculiarities.