feat(web_core): expose theme from ComponentContext

[ppazosp]

Description

Exposes the theme object from SurfaceModel directly on ComponentContext, following the implementation strategy outlined by @jacobsimionato in #976.

This allows component implementations across all renderers to access theme properties (e.g. primaryColor, iconUrl, agentDisplayName) directly from context without traversing the surface model.

Changes

• component-context.ts: Added readonly theme: any property, assigned from surface.theme in the constructor
• component-context.test.ts: Added 2 tests — verifies theme is exposed when provided and defaults to {} when not

All 255 existing web_core tests pass.

This is a prerequisite for wiring up consistent theme support across all renderers, complementing #1025 (React CSS variable injection).

Closes #976

Pre-launch Checklist

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have added updates to the CHANGELOG.
• I updated/added relevant documentation.
• My code changes (if any) have tests.

If you need help, consider asking for advice on the discussion board.

[gemini-code-assist]

Code Review

This pull request adds a theme property to the ComponentContext class, allowing components to access theme configurations from the surface. Unit tests were included to verify that the theme is correctly exposed and defaults to an empty object. A review comment suggests replacing the any type with Record<string, any> to improve type safety.

[gemini-code-assist]

Using any for the theme property forfeits TypeScript's type safety benefits. While the source surface.theme is also of type any, we can improve clarity and type safety here by using a more descriptive type. Record<string, any> makes it clear that theme is an object with string keys, which is a good improvement over a plain any and helps with future maintenance.

Suggested change

	readonly theme: any;
	readonly theme: Record<string, any>;

[ppazosp]

I intentionally matched the type from SurfaceModel.theme (any) to keep them consistent. Changing only this side to Record<string, any> would create a mismatch between the source and the consumer. If the team decides to strengthen the type on SurfaceModel, this should follow along with it.