chore: Add prefix for Redis keys

[alexandreferris]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

Redis/Valkey in staging cluster can only access keys from specific namespace

Solutions

Add a prefix with namespace naming

[claude]

PR Review: Add prefix for Redis keys

Thanks for this! The change is small, focused, and does exactly what the description says. Extracting STORAGE_KEY_PREFIX into a single const and applying it consistently to both toStorageKey overloads is clean and keeps the two key formats in sync. 👍

🔴 Backward compatibility / data migration (main concern)

This is the one thing I'd want confirmed before merge. Adding the prefix changes the key format, so any secret already stored in Redis under the old un-prefixed key becomes unreachable. The impact chain is subtle but user-visible:

• EventsHandler.formatSetupInstructions() does secret ?: run { generate + store }. For a conversation that already has a secret, storage.get(...) will now return null (old key), so the app silently generates a brand-new secret.
• The user's existing GitHub webhook is still configured with the old secret, so SignatureValidator.isValid() will now fail HMAC validation for every incoming webhook until they re-run setup with the new secret.

If this only targets the staging cluster (as the description suggests) and there's no production data to preserve, this may be perfectly acceptable — but it's worth a conscious decision. Options if migration matters:

• Run a one-off rename/migration of existing keys (RENAME oldKey newKey), or
• Read-fallback to the un-prefixed key on a miss for a deprecation window, or
• Explicitly document that existing conversations must re-run setup.

🟡 Minor

• Namespace separator convention: the resulting key is github-app:{id}@{domain}. Using : as the namespace delimiter follows Redis convention nicely, but note the domain is still joined with @ while the namespace uses : — mixing delimiters is fine functionally, just something to be aware of for future key parsing / SCAN github-app:* tooling.
• Test coverage: there's no unit test asserting the produced key format (Extensions.kt isn't covered by ApplicationTest). Since the exact key string is now security/routing-relevant (a mismatch silently breaks signature validation), a couple of tiny assertions would guard against accidental format changes:

  QualifiedId(id, domain).toStorageKey() shouldBe "github-app:$id@$domain"
  id.toStorageKey(domain) shouldBe "github-app:$id@$domain"

✅ Security / performance

No concerns — the prefix is a constant, no extra allocations of note, and no sensitive data is exposed by the key format itself.

Overall LGTM once the migration / existing-key behavior is confirmed as intended for the target environment.