sam commands in codecatalyst dev env may fail if they inherit the local setting

## Problem

sam cli commands fail in codecatalyst remote dev envs if the `aws.samcli.location` setting is set in "user" settings (i.e. on the local machine).

## Steps to reproduce the issue

1. set `aws.samcli.location` to something on the local vscode settings (aka "User" settings).
- note: must be different than `/usr/local/bin/sam`
2. open a codecatalyst dev env
3. run the `AWS: Create Lambda SAM Application` command
4. the command fails:
```
2024-04-04 21:42:46 [INFO]: SAM CLI location (from settings): /opt/homebrew/bin/sam
2024-04-04 21:42:46 [ERROR]: Error creating new SAM Application. Check the logs by running the "View AWS Toolkit Logs" command from the Command Palette.
2024-04-04 21:42:46 [ERROR]: Error creating new SAM Application: 'Error: SAM CLI has an invalid version [InvalidSamCliVersion]'
```

## Expected behavior

When running in a remote context (vscode remote-ssh), sam functionality in the Toolkit should ignore the "User" scoped `aws.samcli.location` setting inherited from the local machine. Because the local machine path is usually not valid for a remote machine.

## Proposal

- Declare `aws.samcli.location` with a different scope?
- When running in a remote context, ignore `aws.samcli.location` inherited from "User"/Global scope.

Start by tracing how the Toolkit reads the `aws.samcli.location` setting and detects a VS Code remote context, then reproduce the failure with a user-scoped local path in a CodeCatalyst dev environment. Done means SAM commands use a valid remote setting or ignore the inherited local path, while continuing to work locally.

Written by the indexing model from the issue text.