fix(m15): change planted secret pattern + note hosted-forge push protection

The previous planted SYNC_API_KEY used a sk_live_-prefixed value that
pattern-matches Stripe, so GitHub push protection blocked the public mirror push
before any of the module's own gates ran. Swap it for a generic high-entropy
value the secret-keyword detector still flags (var name is SYNC_API_KEY) without
matching any specific issuer pattern.

Add a "Gate 0: your hosted forge" note to M15 acknowledging that the forge's own
push protection is the earliest gate; teach learners to treat it that way rather
than papering over a bypass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

modules/15-security-scanning/README.md

@@ -432,6 +432,15 @@ runs on every push and blocks the merge.
 
 ---
 
+### Gate 0: your hosted forge
+
+Most hosted forges run their own secret scanner on every push and reject the push if it finds a
+recognized key pattern (GitHub calls this *push protection*; GitLab and others have equivalents).
+That happens **before** any CI you wrote runs, so it is effectively *Gate 0* in this module. The
+planted `SYNC_API_KEY` in `lab/config.py` uses a generic high-entropy value (not an issuer
+pattern) so the lab can ship; in your real repo, treat your forge's push protection as the
+earliest gate and never paper over a bypass.
+
 ## Where it breaks
 
 The honest limits (these gates are necessary, not sufficient):

modules/15-security-scanning/lab/config.py

@@ -14,7 +14,7 @@ import hashlib
 
 # --- The problem the SECRET scanner should flag (Gate 2) ---------------------------------------
 # A hardcoded API key. Looks like a normal string literal; lint and tests will never complain.
-SYNC_API_KEY = "sk_live_9c3f2a7b41d84e0fa6b2c5d8e1f09a73bdac46"
+SYNC_API_KEY = "k7c9f2a4b8d6e1039284756abcdef0123456789abcdef0123456789abcdef0123"
 SYNC_ENDPOINT = "https://api.example-task-cloud.com/v1/sync"