feat(provider): add GitHub Models provider (chat + embeddings)

[pratyushuniv2022-code]

Closes #171.

Summary:

• Add GitHubModelsClient and GitHubProvider to support GitHub Models inference endpoints.
• Add unit tests (mocked) at src/test/... to validate provider parsing without network/Docker.
• Add example workflow at examples/github-provider-example.yaml.

Notes:

• Local build done with ./gradlew build -x test. Integration tests that require Docker were not run locally.
• Unit tests provided should pass in CI without Docker. Please let me know if maintainers want integration tests added (they require Docker/model pulls).

PR readiness checklist

• Code compiles locally: ./gradlew clean build -x test ✅
• Unit tests added and passing: ./gradlew test --tests "io.kestra.plugin.ai.provider.github.GitHubProviderTest" ✅
• Example workflow added: examples/github-provider-example.yaml ✅
• No secrets committed; token usage shown via {{ secrets.GITHUB_MODELS_TOKEN }} ✅
• Integration tests (Docker/Testcontainers) not run locally due to Docker / model pulls; CI should run those. Please let me know if maintainers want me to add integration tests or adjust tags to run them in Docker-enabled CI.

[MilosPaunovic]

Just a small note for the future, if you could use GitHub Keywords when opening PRs to connect it to the proper issue (to automate the entire process a bit more), it would be super helpful to us. You can read a bit more about it here (I've added closing keyword for this particular issue).

[Malaydewangan09]

Hey @pratyushuniv2022-code, thanks for the contribution! 🚀
Did you gave a look at already existing providers on how they have been implemented?
for ref

[pratyushuniv2022-code]

Just a small note for the future, if you could use GitHub Keywords when opening PRs to connect it to the proper issue (to automate the entire process a bit more), it would be super helpful to us. You can read a bit more about it here (I've added closing keyword for this particular issue).

Hey @pratyushuniv2022-code, thanks for the contribution! 🚀
Did you gave a look at already existing providers on how they have been implemented?
for ref

Hey @Malaydewangan09 and @MilosPaunovic just to confirm the expected implementation style before I proceed:
Currently, my GitHubProvider uses a lightweight custom adapter (GitHubModelsClient) that directly handles the HTTP requests and response parsing for chat/embeddings.
I noticed other providers (like OpenAI and Anthropic) are implemented through LangChain4j’s ChatModel abstraction.
Would you prefer that I refactor this to wrap my client in a LangChain4j ChatModel (e.g., GitHubLangChainChatModelAdapter) so it’s consistent with the rest of the ecosystem or is the current direct approach acceptable for now?
Happy to align it whichever way you’d prefer. Also open to any other suggestions or improvements you might have.

[Malaydewangan09]

Yes, @pratyushuniv2022-code that would be great, thanks!

[fdelbrayelle]

Hello @Pratyushstark 👋 Any update on this one?

[Malaydewangan09]

Hey @pratyushuniv2022-code 👋, are there any updates on this?