[Ubuntu 26.04][CLI&UX] credentials add reports a wrong-identity gateway and an unreachable gateway with the same message

## Description

When the selected OpenShell gateway endpoint points at something that answers HTTP but is
not a NemoClaw gateway, nemoclaw credentials add fails with exactly the same message it
prints when nothing is listening at all. The user cannot tell "you reached something that
is not your gateway" from "your gateway is not running", and those two conditions have
different remedies.

Both cases end in the identical two-line message telling the user to start the gateway,
which is the wrong instruction for the first case.

This is a diagnostic defect, not a security bypass. The command does refuse in both cases
and no provider is created.

Note on the repro: the provider endpoint value below is not important. Both attempts fail
at the gateway-connection stage before the endpoint is ever validated, so any accepted
public IP-literal endpoint reproduces this.

Platform scope: Reproduced on Ubuntu 26.04 x86_64 only; other platforms not tested.
Regression: Unknown - earlier versions not tested for this path.
OpenShell issue: No

## Environment

```text
Device: Ubuntu 26.04 host, x86_64
OS: Ubuntu 26.04 LTS
Architecture: x86_64
Node.js: v22.23.2
npm: Not on PATH (installer-managed Node.js)
Docker: Docker version 29.7.2, build a7dcaa6
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.121
OpenClaw: 2026.7.1
```

## Steps to Reproduce

```bash
1. On a host with NemoClaw onboarded and its real gateway selected and healthy, start a
plain HTTP responder on loopback port 18081 that answers every request with HTTP 200
and is NOT an OpenShell gateway. Any small http.server stub works.

2. Confirm nothing is listening on loopback port 18082.

3. Export a synthetic credential value:

export QA_SYNTH_KEY="synthetic-marker-value"

4. Point the gateway endpoint at the responder and try to add a provider, supplying any
accepted public IP-literal endpoint for the provider config:

OPENSHELL_GATEWAY_ENDPOINT=http://127.0.0.1:18081 nemoclaw credentials add \
qa-ambient --type openai --config OPENAI_BASE_URL="{public-ip-literal-endpoint}" \
--credential QA_SYNTH_KEY

5. Point the gateway endpoint at the port where nothing is listening, same provider
config:

OPENSHELL_GATEWAY_ENDPOINT=http://127.0.0.1:18082 nemoclaw credentials add \
qa-unreach --type openai --config OPENAI_BASE_URL="{public-ip-literal-endpoint}" \
--credential QA_SYNTH_KEY

6. Compare the two messages.
```

## Expected Result

The two conditions are distinguishable. A gateway endpoint that responds but is not the
expected gateway is reported as a wrong, untrusted or mismatched gateway selection, and a
port with nothing listening is reported as unreachable. The remedy offered matches the
condition.

## Actual Result

Step 4, responder present but not a gateway, verbatim tail:

[2/8] Starting OpenShell gateway
Starting OpenShell Docker-driver gateway via managed service...
OpenShell gateway managed service is healthy
Could not reach the NemoClaw OpenShell gateway. Is it running?
Start the gateway again with `nemoclaw onboard`.

exit code 1

Step 5, nothing listening, verbatim tail:

Could not reach the NemoClaw OpenShell gateway. Is it running?
Start the gateway again with `nemoclaw onboard`.

exit code 1

The final message is byte for byte identical in both cases. Neither indicates that in
step 4 the CLI actually reached something that was not the expected gateway.

In both cases the command refused and the provider was not created, confirmed with
nemoclaw credentials list. The synthetic credential value did not appear in any captured
output.

A separate check confirmed the responder received only unauthenticated liveness probes
with no credential material, so there is no credential-transport concern here - only the
indistinguishable diagnostics.

## Logs

```text
Not captured beyond the terminal output quoted in Actual Result.
```

Start at the `nemoclaw credentials add` command and trace how it handles the OpenShell gateway response and connection failure. Reproduce the two endpoint cases from the issue, then verify that a reachable non-gateway produces a distinct diagnostic while an unreachable port retains its unreachable message and no provider is created.

Written by the indexing model from the issue text.