temporal-spring-ai: per-model ActivityOptions registry

[donald-pinckney]

Based on

• temporal-spring-ai: attach activity summaries for chat and MCP calls #2852 — spring-ai/activity-summaries — adds the chat/MCP Summary plumbing
• temporal-spring-ai: accept ActivityOptions and classify non-retryable AI errors #2853 — spring-ai/retry-and-options — adds the ActivityOptions factory overloads and defaultActivityOptions() this PR builds on

Merge those in order first; this PR will retarget each time an ancestor lands.

---

What was changed

• New SpringAiPluginOptions static registry (package io.temporal.springai.plugin). SpringAiPlugin publishes a Map<String, ActivityOptions> to it on construction; ActivityChatModel.forModel(String) / forDefault() consult it before falling back to the plugin defaults.
• SpringAiPlugin gains a third constructor that accepts the per-model map; the two existing constructors delegate with an empty map. No constructor changes to existing SpringAiPlugin(ChatModel) / SpringAiPlugin(Map, ChatModel) call sites.
• New ChatModelActivityOptions record (package io.temporal.springai.autoconfigure) — a thin wrapper around Map<String, ActivityOptions> — exists so SpringAiTemporalAutoConfiguration can inject user options by type rather than by bean name. Raw Map<String, ActivityOptions> injection would trigger Spring's collection-of-beans autowiring and sweep in any unrelated ActivityOptions bean in the context. Using a dedicated wrapper type avoids that collision and keeps the design consistent with temporal-spring-ai: discover MCP clients by type, not by bean name #2859 (MCP bean lookup by type, not by name).
• SpringAiTemporalAutoConfiguration injects ObjectProvider<ChatModelActivityOptions> and forwards the wrapped map to the plugin. No magic bean name, no @Qualifier.
• Callers who pass explicit ActivityOptions via forModel(name, options) / forDefault(options) bypass the registry entirely. The (timeout, maxAttempts) convenience factory is unaffected — it still builds options from its arguments.
• Tests: PerModelActivityOptionsTest covers the three cases in the plan — registry hit uses the registered startToCloseTimeout, registry miss falls back to the 2-minute default, explicit options bypass a populated registry entry.

Why?

A single default (2 min start-to-close, 3 attempts) doesn't fit every model. Reasoning and thinking-mode models need more time; fast models want shorter timeouts so retries recover quickly. The Temporal AI integration guide specifically calls this out as a capability partners should expose. With this change, users register one bean and never have to hand-build activity stubs again.

Example user config:

@Bean
ChatModelActivityOptions chatModelActivityOptions() {
    return new ChatModelActivityOptions(Map.of(
        "reasoning", ActivityOptions.newBuilder(ActivityChatModel.defaultActivityOptions())
            .setStartToCloseTimeout(Duration.ofMinutes(15))
            .build()));
}