Initialize session provider metadata from global config

[i386]

Summary

This fixes two related session metadata issues in goose-server:

• POST /agent/start now initializes new sessions with the active global provider and model when there is no recipe override.
• POST /agent/resume now always refetches the session after provider restore so the response reflects the persisted provider/model instead of returning stale null fields.

These changes make freshly created and resumed sessions report the same provider/model state that the backend is actually using.

Changes

• initialize session provider_name and model_config from Config::global() during start_agent
• preserve recipe settings as the higher-priority override path
• always refetch the session in resume_agent after restore_provider_from_session
• add route-level regression tests covering:
  • new sessions inheriting the global provider/model
  • resumed sessions returning restored provider/model metadata
• add serial_test and tempfile as goose-server test dependencies to isolate GOOSE_PATH_ROOT safely in those regressions

Why

This showed up while validating flock against Goose’s external backend APIs:

• a new session could be created with provider_name = null and model_config = null even though the backend had an active global provider/model configured
• resuming a session could restore the provider internally but still return the old session snapshot, so clients saw missing provider metadata

That combination made external-backend clients think the session had no configured provider/model even when Goose could recover it.

Validation

• cargo test -p goose-server routes::agent -- --nocapture

Notes

• I also ran just generate-openapi. Backend schema generation succeeded, but the frontend SDK generation step failed in this environment because npx @hey-api/openapi-ts could not resolve get-tsconfig@4.13.6.