Feat: Use AuthPreprocessor in LlmAgent

[AmaadMartin]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

Closes: #
Related: #

2. Or, if no issue exists, describe the change:

Problem:
Previously, LlmAgent did not have a mechanism to handle tool authentication flows. If a tool required authentication (e.g., API key, OAuth), there was no standard way to pause execution, request credentials from the user, store them, and resume tool execution.

Solution:
This PR implements AuthPreprocessor in LlmAgent and integrates it with RestApiTool to support authenticated tool execution.

Key changes:

• AuthPreprocessor: A new request processor registered by default in LlmAgent. It intercepts the flow when a tool returns a pending auth status, yields a credential request event, and pauses execution. When the user provides the credentials, it stores them and retries the failed tool before resuming the LLM interaction.
• isFinalResponse Update: Modified isFinalResponse in core/src/events/event.ts to return true when auth configs are requested. This ensures the runner stops and waits for user input.
• RestApiTool: Implemented a tool that represents an OpenAPI operation. It uses ToolAuthHandler to check for credentials and returns a pending status if credentials are required but missing.
• Exports: Exported AUTH_PREPROCESSOR, AuthPreprocessor, and RestApiTool in core/src/common.ts.

Testing Plan
Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

We added/updated the following test suites:

• core/test/auth/auth_preprocessor_test.ts: Tests AuthPreprocessor logic.
• core/test/agents/llm_agent_auth_integration_test.ts: Integration test simulating the full auth request/resume flow with a mock LLM and a local HTTP server.
• core/test/events/event_test.ts: Tests isFinalResponse with requested auth configs.
• core/test/tools/openapi_tool/rest_api_tool_test.ts: Tests RestApiTool credential handling and request preparation.

All tests passed locally (90 tests in total).

Manual End-to-End (E2E) Tests:
We added an E2E test: tests/e2e/tools/rest_api_tool_auth_e2e_test.ts which runs a local server and uses a real Gemini model to verify the auth flow.
Note: This test is skipped locally if GEMINI_API_KEY (or equivalent) is not set in the environment.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.

[kalenkevich]

Do you know why it is like that?

Can we camelCase all the values somehow not to introduce such types?

[AmaadMartin]

I agree that we should avoid duplicate types. I have refactored this by adding a recursive camelCaseKeys utility to normalize all incoming event arguments in AuthPreprocessor. This allowed us to simplify the RequestCredentialArgs interface to only contain camelCase fields, while maintaining compatibility with snake_case arguments sent by Python or other clients. I also added unit tests to verify this normalization.