Harden LORIS API integration

[Andesha]

Summary

Harden the existing LORIS API integration across connection state, error messaging, recording-parameter validation, and TLS behavior.

This consolidates #78, #101, #126, and #153. The scope is improving the reliability and safety of existing integration, not adding arbitrary new LORIS functionality.

Problem

The current workflow needs clearer handling for password errors, malformed or unreachable URLs, and logged-in/logged-out status. A failed connection attempt can also leave an error visible after a later attempt succeeds, presenting contradictory state to the user.

Recording parameters that can be cross-referenced against LORIS are not currently validated before submission. The relevant fields and authoritative LORIS data still need to be identified.

The LORIS API client also passes verify=False to requests, disabling TLS certificate verification. The replacement behavior must account for deployments using private certificate authorities.

Because the original reports predate the current unified workflow, first verify each behavior against the current application.

Scope

Connection state and error messaging

• Distinguish malformed URL, authentication failure, and connection failure where the backend provides enough information.
• Show a clear logged-in or logged-out state in the wizard.
• Clear stale connection errors after a successful retry.
• Avoid showing success and failure states at the same time.
• Keep messages actionable without exposing credentials or sensitive response details.

Recording-parameter validation

• Identify which recording-parameter fields can be validated against LORIS and which LORIS data is authoritative for each.
• Validate those fields before submission.
• Present actionable, field-level validation errors.
• Define behavior when LORIS is unavailable, preserving the application's optional-LORIS workflow.

TLS behavior

• Review TLS verification throughout eeg2bids/loris_api.py.
• Verify certificates by default.
• Support deployments that use private certificate authorities through an agreed configuration mechanism.
• Document the resulting configuration and behavior.

Acceptance criteria

• Current integration behavior and relevant states are verified and documented.
• A malformed URL produces an actionable message.
• Invalid credentials produce an appropriate authentication message.
• A successful retry clears errors from earlier failed attempts.
• The wizard accurately communicates whether the user is logged in.
• Recording-parameter fields that can be cross-referenced are identified together with their authoritative LORIS data.
• Supported recording parameters are validated before submission with actionable field-level errors.
• Validation behavior when LORIS is unavailable is defined and tested.
• TLS certificates are verified by default, with documented support for private certificate authorities.
• Automated tests cover connection failures, failure followed by a successful retry, parameter validation, and TLS configuration.