Establish provider-scoped configuration pattern

[ChristianPavilonis]

Problem

The config-store/runtime-config work on this branch introduces a strong Fastly-specific shape into places that should either be provider-neutral or explicitly provider-scoped. This works for the current Fastly adapter, but it will make future adapters harder to add because application config, runtime resource references, and CLI provisioning are currently mixed together.

We should establish a provider-scoped configuration pattern so Fastly-specific deployment values live under an explicit Fastly provider namespace instead of being spread across core settings, hardcoded constants, CLI flags, and docs.

Current Fastly-specific coupling

Application config store name/key

crates/trusted-server-core/src/runtime_config.rs defines:

pub const APPLICATION_CONFIG_STORE_NAME: &str = "ts_config_store";
pub const APPLICATION_CONFIG_KEY: &str = "ts-config";

ts-config may be a provider-neutral application config key, but ts_config_store is a Fastly-style config-store binding name. These constants are used by the Fastly adapter, CLI provisioning, local dev rendering, and docs.

Request-signing management IDs in app config

trusted-server.toml currently has:

[request_signing]
enabled = true
config_store_id = ""
secret_store_id = ""

Those IDs are Fastly management API store IDs. They are required for Fastly key rotation writes, but they are not application behavior and may not exist for another provider.

Request-signing runtime store names fixed in core

crates/trusted-server-core/src/request_signing/mod.rs defines:

pub const JWKS_CONFIG_STORE_NAME: &str = "jwks_store";
pub const SIGNING_SECRET_STORE_NAME: &str = "signing_keys";

These are runtime store/binding names for the current Fastly deployment model. Core currently dictates provider resource names.

Runtime Fastly API token store is hardcoded

Fastly provisioning uses:

const FASTLY_API_SECRET_STORE_NAME: &str = "api-keys";
const FASTLY_API_SECRET_KEY: &str = "api_key";

The legacy runtime API client also defaults to api-keys/api_key. This is Fastly-specific runtime management plumbing.

Provisioning requires --service-id

The CLI requires:

ts provision fastly plan --service-id svc_123
ts provision fastly apply --service-id svc_123

But fastly.toml already has service_id. This is provider deployment config and should be resolvable from a provider config section or provider-native manifest.

Local dev projection is Fastly-specific

ts dev renders fastly.local.toml and injects:

[local_server.config_stores.ts_config_store]
format = "inline-toml"

[local_server.config_stores.ts_config_store.contents]
ts-config = "..."

This projection should be owned by the Fastly provider configuration/adapter path.

Possible solution for now: provider sections in trusted-server.toml

As a near-term pattern, add an explicit provider namespace to the existing config file. This keeps operator UX simple while making provider-owned values visible and clearly scoped.

Example shape:

[publisher]
domain = "example.com"
origin_url = "https://origin.example.com"
cookie_domain = ".example.com"
proxy_secret = "..."

[edge_cookie]
secret_key = "..."

[request_signing]
enabled = true

[providers.fastly]
service_id = "svc_123"

[providers.fastly.application_config]
store_name = "ts_config_store"
key = "ts-config"

[providers.fastly.request_signing]
jwks_store_name = "jwks_store"
jwks_store_id = "..."
signing_secret_store_name = "signing_keys"
signing_secret_store_id = "..."
runtime_api_secret_store_name = "api-keys"
runtime_api_secret_key = "api_key"

This would let us move Fastly-only values out of the provider-neutral sections while keeping a single TOML file for now.

Notes on this option

Pros:

• Simple one-file operator workflow.
• Makes Fastly-specific values explicit and namespaced.
• Lets ts provision fastly resolve service_id from config, with --service-id as an override if needed.
• Creates a place for future provider-specific defaults without spreading constants across core/CLI/docs.

Tradeoffs:

• trusted-server.toml becomes both app config and provider/deployment config.
• We need to decide whether provider sections are included in canonical app config and config hash.
• Longer term, we may still want a separate deployment/provider config file if we need multiple providers/environments for the same app config.

Acceptance criteria

• Add an explicit provider config model, starting with providers.fastly.
• Move or deprecate Fastly management fields from provider-neutral sections, especially request_signing.config_store_id and request_signing.secret_store_id.
• Make Fastly app config store settings provider-scoped, with current values as defaults.
• Make Fastly request-signing store names/IDs provider-scoped, with current values as defaults.
• Make runtime Fastly API token secret location provider-scoped, with api-keys/api_key as the default.
• Allow ts provision fastly plan/apply to resolve service_id from provider config and/or fastly.toml, keeping --service-id as an override.
• Document app config vs provider config semantics.
• Decide and document whether provider config participates in canonical app config hashing.
• Add tests for provider config parsing and CLI resolution precedence.