Persisted context TLS settings are inconsistent for different HTTPS servers

Nessuno ha ancora preso questa issue.

### Describe the bug

The CLI stores TLS settings in the local server context, but the current behavior is inconsistent:

1. `microcks login` always persists `insecureTLS: true`, even when the user did not pass `--insecure-tls`.
2. Later commands that load the saved context do not honor the persisted `insecureTLS` value when building the HTTP client.

This makes saved HTTPS contexts misleading. A context can contain `insecureTLS: true`, but commands such as `import`, `import-url`, `import-dir`, and `test` still fail unless `--insecure-tls` is repeated.

This affects Microcks instances exposed over HTTPS with self-signed certificates, private CA certificates, local ingress TLS, or internal reverse proxies.

Common examples:

- Microcks behind local `k3s` / ingress TLS
- Microcks behind Caddy, nginx, Traefik, or an internal gateway
- Instances using private PKI

### Expected behavior

If the user logs in with `--insecure-tls`, later commands using that saved context should honor the persisted TLS setting.

If the user logs in without `--insecure-tls`, the saved context should not be marked insecure.

### Actual behavior

_No response_

### How to Reproduce?

Given a Microcks server available at an HTTPS endpoint with a self-signed or private certificate:

```sh
microcks login https://microcks.example.local --insecure-tls
```

This succeeds and stores:

```yaml
server: https://microcks.example.local
insecureTLS: true
```

But a later command using the saved context can fail:

```sh
microcks import openapi.yaml
```

with an error like:

```text
tls: failed to verify certificate: x509: certificate signed by unknown authority
```

Repeating the flag makes the same command work:

```sh
microcks import openapi.yaml --insecure-tls
```

Start by tracing how the `login` command persists the local server context and how `import`, `import-url`, `import-dir`, and `test` build their HTTP clients. Verify both login paths and saved-context loading: `--insecure-tls` should persist and be honored later, while login without it should not mark the context insecure.

Scritto dal modello di indicizzazione a partire dal testo della issue.