Add tri-state reasoning overrides

docs/roadmap/future.md

@@ -69,30 +69,6 @@ admitted call would wait for and return its ordinary result.
   polling, priorities, application worker lifecycle, retries, and
   cross-process coordination would be separate future capabilities.
 
-### Explicit per-run session and reasoning controls
-
-Allow consumers to associate a session ID with each run and to inherit,
-replace, or explicitly disable the reasoning effort configured by its selected
-profile. Prompt definitions can currently derive a session ID from a template,
-and a non-empty runtime `ReasoningEffort` can replace the profile value, but
-there is no direct request-level session ID and an empty reasoning value means
-that no override was supplied. These controls would let consumers reuse one
-prompt and model profile across sessions and reasoning levels without
-maintaining duplicate definitions.
-
-- Preserve a prompt's session ID template and a profile's reasoning effort as
-  reusable defaults.
-- Let a directly supplied per-run session ID take precedence over a rendered
-  prompt default while retaining the existing validation limit and outbound
-  representation.
-- Distinguish an omitted runtime reasoning choice from an explicit request to
-  disable reasoning.
-- Ensure disabling reasoning omits the corresponding provider request setting
-  rather than relying on a provider-specific magic value.
-- Keep the effective session ID and reasoning choice visible in prepared and
-  run metadata and available to injected model clients without introducing
-  additional prompt or profile selection mechanisms.
-
 ## Entry Format
 
 Use a short heading followed by a concise summary. Add focused bullets when