Move request-signing Fastly management IDs out of application config

[ChristianPavilonis]

Problem

Issue #683 introduced provider-scoped Fastly deployment config, but intentionally left request-signing Fastly management IDs in [request_signing] as deprecated fields:

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

These IDs are Fastly management API store IDs used by runtime key-rotation writes. They are not provider-neutral application behavior, so they should not live in canonical application config long term.

Current state

• [providers] is excluded from canonical app config/hash/upload.
• Runtime key rotation still reads:
  • request_signing.config_store_id
  • request_signing.secret_store_id
• FastlyApiClient::new() still defaults to api-keys/api_key.
• Runtime-opened stores use fixed Fastly resource-link aliases:
  • jwks_store
  • signing_keys
  • api-keys

Proposed solution

Add a runtime-readable Fastly provider config payload that is separate from canonical app config.

One possible shape:

• Keep canonical app config under:
  • store alias: ts_config_store
  • key: ts-config
• Add provider runtime config under:
  • store alias: ts_config_store
  • key: ts-fastly-provider-config

Example payload:

[request_signing]
jwks_store_id = "..."
signing_secret_store_id = "..."
runtime_api_secret_store_name = "api-keys"
runtime_api_secret_key = "api_key"

Then runtime key rotation reads Fastly management IDs from this provider runtime config instead of [request_signing].

Acceptance criteria

• Add a runtime-readable Fastly provider config model for request-signing management settings.
• CLI provisioning writes/updates this provider runtime config separately from canonical app config.
• Runtime key rotation reads jwks_store_id and signing_secret_store_id from provider runtime config.
• FastlyApiClient can use configured runtime API secret store/key instead of hardcoded api-keys/api_key.
• Deprecated [request_signing].config_store_id and secret_store_id remain temporarily supported as fallback.
• Emit clear deprecation warnings when fallback fields are used.
• Provider runtime config does not affect canonical app config hash.
• Add tests for migration/fallback behavior.
• Update docs to distinguish:
  • app config
  • provider deployment config
  • provider runtime config

Notes

This should complete the request-signing part intentionally deferred from #683.