external providers for lecturers data

## Summary
Implement an Anti-Corruption Layer (ACL, more info: [1](https://oneuptime.com/blog/post/2026-01-30-anti-corruption-layer-pattern/view), [2](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/acl.html), [3](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)) and a design pattern (e.g., strategy) to unify the fetching of lecturer data from multiple external sources (USOS, Informator PP, lecturer websites).

## [Acceptance criteria](https://www.atlassian.com/work-management/project-management/acceptance-criteria)
- [ ] Define a common interface in the Application layer.
- [ ] Implement concrete providers in the Infrastructure layer for different external systems.
- [ ] Utilize the already existing `IUsosHttpClient` for USOS integration. (Do not introduce retry mechanisms at this stage).
- [ ] Providers translate raw external structures into unified DTOs understood by our domain.
- [ ] In case of external API unavailability, methods return a `Result.Failure` object instead of throwing exceptions.

## Notes
The focus here is solely on a data extraction mechanism. Providers must isolate the rest of the application from changes in the USOS API or HTML on lecturers websites. A single interface allows us to easily plug in new data sources in the future.

This task should focus only on external providers, not storing this data in db, returning from api, etc.

Locate the Application and Infrastructure layers and inspect the existing IUsosHttpClient first. Then identify the external systems and the domain DTOs involved in lecturer data extraction. Done means a common interface, concrete providers that translate each source, and Result.Failure responses for unavailable external APIs without adding storage or API-return work.

Escrita pelo modelo de indexação a partir do texto da issue.