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()));
}

[brianstrauch]

How would you feel about having two ways to initialize? (1) default activity options, or (2) explicit options. Combining the default options with explicit options makes it confusing what the final options are.

[donald-pinckney]

@brianstrauch Just so we're clear, default options and explicit options don't get merged together ever, but what I think is confusing at the moment is that there is a fallthrough path of: no matching entry in perModelOptions -> use plugin builtin defaults. I don't think thats clear, and also isn't controllable by the user.

I suggest a very simple tweak to this PR, where perModelOptions can have a special ChatModelTypes.DEFAULT_MODEL_NAME key, which will act as a user-provided global fallback. This makes sense, as its a nice parallel structure to ChatModelTypes.DEFAULT_MODEL_NAME being the key for the default model to fallback to.

Specifically:

• perModelOptions keys may be:
  • a ChatModel bean name: per-model override
  • the literal ChatModelTypes.DEFAULT_MODEL_NAME ("default"): acts as a user-declared global fallback
  • Any other key: IllegalArgumentException at plugin construction (typo safety).
• Lookup of options in forModel(name):
  a. perModelOptions[name] if present
  b. else perModelOptions["default"] if present
  c. else library defaults
• Lookup in forDefault():
  a. perModelOptions["default"] if present
  b. else library defaults