feat: API key and token patterns in credential detection

[ksek87]

Problem

CredentialReference (FUZZD-002) and RuntimeCredentialAccess (FUZZD-026) only match file paths to credential stores (~/.ssh/id_rsa, .aws/credentials, .env, etc.). In-memory credential formats — AWS access keys, Bearer tokens, JWTs, GCP service account JSON — are not detected even though they appear frequently in real-world exfiltration payloads and runtime arguments.

From the MCPTox and MCPLIB datasets, known in-memory credential formats that appear in attack payloads include:

• AWS access key IDs: AKIA[A-Z0-9]{16} prefix
• AWS session tokens and ARNs: arn:aws: prefix
• Bearer / Authorization header values: Bearer , token , Authorization:
• JWT tokens: eyJ base64 prefix (header.payload.signature)
• GCP service account JSON: "type": "service_account" shape
• Database connection strings: postgresql://, mongodb://, mysql://
• Generic API keys: _api_key, _secret_key, _access_token suffix patterns in argument names

Acceptance criteria

Static scanner (description.rs)

• Extend CredentialReference patterns with in-memory format needles (AKIA, Bearer, eyJ, arn:aws:, service_account, connection string prefixes)
• Add patterns for API key argument-name suffixes (_api_key, _secret, _token in inputSchema field names)
• Verify 0 new FP on bench/clean_tools.json after additions

Sequence analyzer (analyzer/sequence.rs)

• Extend CREDENTIAL_MARKERS in RuntimeCredentialAccess detection to include the same in-memory formats
• Add regex-based detection for AKIA[A-Z0-9]{16} and eyJ[A-Za-z0-9+/] patterns in runtime argument values

Corpus

• Add corpus records for in-memory credential exfiltration payloads (JWT theft, AWS key exfiltration)

Tests

• Unit tests: each new pattern fires on a synthetic payload
• Unit tests: clean tools don't trigger new patterns