feat(models): decouple healthcheck to other capabilities

[leoguillaume]

• Convert check capabilities into standard forward request method
• Unify BaseModelProvider into a single file rename ModelProvider (move to helpers)

In general, to fix a signature mismatch for an overriding method, the subclass method must accept at least the same parameters as the base method (and usually in the same order, with compatible defaults). Here, ModelHttpClient.format_audio_transcription_request expects 2 positional parameters, while AlbertModelHttpClient.format_audio_transcription_request only declares one (request_content). The safest fix is to change the overriding method’s signature to also accept the second parameter and forward it appropriately (or simply ignore it if not needed), without altering existing behavior for the single-argument case.

Given we cannot change the base class and we must preserve current functionality, we will:

• Update AlbertModelHttpClient.format_audio_transcription_request to accept a second argument with a default value that matches the base method’s signature as closely as we can infer.
• Keep the body logic the same, operating only on request_content, so existing behavior is unchanged when the extra argument is not used.
• Keep the @staticmethod decorator if the base method is also static; otherwise we would have a decorator mismatch, but since we must not assume more than given, we only align the parameter list.

Concretely, in api/infrastructure/http/model/_albertmodelhttpclient.py, at the method starting on line 11, we will add a second parameter (named generically as *args or with a specific name if we infer it). Since we do not know the exact parameter name from ModelHttpClient, but we must match “requires 2 positional arguments”, we should add a second explicit positional parameter, e.g. extra, with a harmless default such as None. That way, callers that pass two arguments will succeed, and code that uses only one argument (current behavior) remains unaffected. The method body will stay identical, ignoring the new parameter.

In general, to fix a signature mismatch for an overriding method, you must ensure the overriding method has a compatible signature with the base method it overrides: same number and ordering of required positional parameters (or more permissive, e.g., adding default values or *args, **kwargs), and compatible use of instance/static/class method decorators.

Here, CodeQL says ModelHttpClient.format_audio_transcription_request takes 2 positional arguments, while MistralModelHttpClient.format_audio_transcription_request only takes 1. To fix this without changing the existing behavior, we should:

1. Update the override’s signature to accept the same parameters as the base method. Since we cannot see the base signature, we will follow the pattern of format_response_to_audio_transcription_response, which takes (request_content, response_data) and is also a @staticmethod. It is reasonable to assume the base method for formatting an audio transcription request takes (request_content, response_content) or similar; however, the implementation here clearly only needs request_content. The second argument can be accepted but unused.
2. Keep the method as a @staticmethod to avoid changing how it is called elsewhere.
3. Leave the body unchanged, simply adding the new parameter to the signature (with no default) so that it will accept two positional arguments while continuing to operate solely on request_content.

Concretely, in api/infrastructure/http/model/_mistralmodelhttpclient.py, change the method definition at line 42 from:

@staticmethod
def format_audio_transcription_request(request_content: RequestContent) -> RequestContent:

to:

@staticmethod
def format_audio_transcription_request(request_content: RequestContent, response_data: dict | None = None) -> RequestContent:

Using an optional response_data (with a default) makes the override at least as permissive as the base: it will work when called with one or two arguments. The body does not need to reference response_data, so functionality remains the same. We use a standard dict | None type (Python 3.10+ syntax) without adding imports. If you prefer not to introduce the union syntax, you can instead omit the annotation for the extra parameter or annotate it simply as dict.

In general, the fix is to resolve the merge conflict properly by choosing the correct code from the conflicting branches (or combining them as needed) and removing all conflict markers so that the file is valid Python again.

Here, the conflict is at the very top of api/schemas/audio.py. The two “sides” of the conflict are: one branch that adds import base64 and another that (apparently) only has from enum import StrEnum as the first import. The rest of the file already uses StrEnum and does not reference base64 anywhere in the provided snippet. To avoid changing existing functionality, we should keep the working code (from enum import StrEnum and the subsequent imports and definitions) and remove the conflict markers. Since base64 is unused in the shown code, the safest minimal change is to discard the import base64 line rather than introduce a new unused import that might trigger linting issues; this matches typical conflict resolution when a branch added an import that is no longer needed.

Concretely:

• In api/schemas/audio.py, replace the initial conflict block (lines 1–4 in the snippet) with a single, valid import: from enum import StrEnum.
• Ensure no <<<<<<<, =======, or >>>>>>> markers remain in the file.
  No additional methods, imports, or definitions are required beyond what is already there; we only remove the merge markers and the unused import base64.