Persisted context TLS settings are inconsistent for different HTTPS servers

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:

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

This succeeds and stores:

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

But a later command using the saved context can fail:

microcks import openapi.yaml

with an error like:

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

Repeating the flag makes the same command work:

microcks import openapi.yaml --insecure-tls

まず、login コマンドがローカルサーバーのコンテキストをどのように永続化しているか、また import、import-url、import-dir、test がどのように HTTP クライアントを構築しているかを追跡します。両方の login パスと保存されたコンテキストの読み込みを確認してください。--insecure-tls は永続化され、後で適用されるべきです。一方、このオプションなしで login した場合は、コンテキストを insecure としてマークすべきではありません。