Activates a new @critical @admin-introspection scenario in
features/jwt/jwt_secret_retention.feature that exercises the GET
/api/v1/admin/jwt/secrets endpoint added in PR #51.
The scenario asserts the SECURITY-CRITICAL property: the metadata
endpoint exposes structure (count + per-secret is_primary, age,
fingerprint) WITHOUT leaking secret values. If a future change
accidentally adds the secret value to the response, this test fails
loud:
SECURITY: response leaked the secret value "test-secret-do-not-leak..."
Specifically, the BDD asserts:
- After adding a secondary secret with a known value, GET returns 200
- The response contains 2 secrets in count
- The response does NOT contain the secret value anywhere
- Every entry has a non-empty SHA-256 fingerprint
4 new step definitions added to pkg/bdd/steps/jwt_retention_steps.go:
- iAddASecondaryJWTSecretNamed (parameterised by secret value)
- iRequestTheJWTSecretsMetadataEndpoint
- theMetadataShouldContainNSecrets
- theMetadataShouldNotContainTheSecretValue (the security check)
- everySecretInTheMetadataShouldHaveASHA256Fingerprint
Tests:
- Scenario passes via @admin-introspection tag filter.
- Full BDD suite (auth/config/greet/health/info/jwt) green.
The pre-existing @todo scenarios (Multiple secrets with different ages,
Cleanup frequency configuration, etc.) remain @todo — they require
arbitrary timestamp setup or manual cleanup triggers that aren't
exposed via API, by design. Documented as future test-infrastructure
work.
