Request-signing store selection is inconsistent (hardcoded vs config-driven)

[aram356]

Summary

Store names are hardcoded as "jwks_store" / "signing_keys" in standalone functions but read from settings.request_signing in the admin endpoints. If config and hardcoded values diverge, signing produces keys the verifier cannot find, and key rotation writes to the wrong store.

Refs

• crates/common/src/request_signing/signing.rs line 20 — FastlyConfigStore::new("jwks_store") hardcoded
• crates/common/src/request_signing/signing.rs line 122 — FastlyConfigStore::new("jwks_store") hardcoded
• crates/common/src/request_signing/signing.rs line 130 — FastlySecretStore::new("signing_keys") hardcoded
• crates/common/src/request_signing/jwks.rs line 63 — FastlyConfigStore::new("jwks_store") hardcoded
• crates/common/src/request_signing/rotation.rs line 44 — FastlyConfigStore::new("jwks_store") hardcoded, ignores config_store_id constructor arg
• crates/common/src/request_signing/endpoints.rs line 151 — reads config_store_id/secret_store_id from settings

Recommendation

Single source of truth — either always read store IDs from Settings and thread them through, or document + assert the hardcoded names match config.

Context

Production readiness audit — see #396

[ChristianPavilonis]

I don't think claude understood the difference between the store names and ids.

The ids are required for the write operations, and the names are required for read via the fastly crate. Made a PR to define consts.