fix: prevent nil pointer panic when artifact service is not configured

[123456wda]

When the load_artifacts tool is used without configuring an artifact service, ctx.Artifacts() returns a trackedArtifacts wrapping a nil Artifacts interface. Calling List/Load on this wrapper causes a nil pointer dereference panic.

Changes:

• agent/callback_context.go: In NewToolContext and NewCallbackContextWithArtifactTracking, only wrap Artifacts in trackedArtifacts when the underlying service is not nil. This prevents the nil dereference at the source.
• tool/loadartifactstool/load_artifacts_tool.go: Add nil checks for ctx.Artifacts() in appendInitialInstructions and processLoadArtifactsFunctionCall to return a clear error message instead of panicking.
• tool/loadartifactstool/load_artifacts_tool_test.go: Add two test cases covering nil Artifacts scenarios (ProcessRequest with no function call and with a load_artifacts function call).

Fixes #283

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: #issue_number
• Related: #issue_number

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

If applicable, please follow the issue templates to provide as much detail as
possible.

Problem:
A clear and concise description of what the problem is.

Solution:
A clear and concise description of what you want to happen and why you choose
this solution.

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.

Please include a summary of passed go test results.

Manual End-to-End (E2E) Tests:

Please provide instructions on how to manually test your changes, including any
necessary setup or configuration. Please provide logs or screenshots to help
reviewers better understand the fix.

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.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

Add any other context or screenshots about the feature request here.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[karolpiotrowicz]

Thanks so much for tackling this, and welcome — great first contribution! 🎉 The diagnosis is on the right track and returning a clear error instead of panicking is exactly the right direction.

A few things before we can take this further:

1. Could you confirm the change is tested and share the results?
The checklist still has the testing boxes unchecked and there's no go test output in the description. Could you paste the output of go test ./... so we can see it passing on your branch?

2. Please add a test that reproduces the original panic through the runtime path.
The current tests construct the tool context via agent.NewToolContext, but at runtime the load_artifacts tool receives its context from internal/toolinternal.NewToolContext, which wraps the service in internalArtifacts (see internal/llminternal/base_flow.go → toolPreprocess). The panic in #283 actually originates there (internal/toolinternal.(*internalArtifacts).List), so the key is a test that goes through that path — i.e. exercising the tool the way it's invoked at runtime, with no artifact service configured, and asserting you get a clean error and no panic. I'll leave the exact shape of the test up to you.

It'd be worth double-checking the fix still holds under the runtime path — when ctx.Artifacts() is a wrapper around a nil service rather than a literal nil, the == nil guard may need to live where the wrapper is created. A test through the runtime path will make this unambiguous either way.

3. CLA: the google-cla check is currently failing — please sign the Contributor License Agreement (link is in the failed check) so we're able to review and merge.

4. Checklist: could you complete the checklist in the PR description (contribution guide read, self-review, tests added/passing, manual E2E)? It helps us track readiness.

[wolo-lab]

Thank you for working on it. Closing as duplicate and stale. The PR #1390 is going to solve #283.