fix: secret scan missed every prefixed secret name (db_password, STRIPE_SECRET)

[aoc81]

The bug

The Hardcoded secret assignment rule in plugin/scripts/scan_secrets.py wrapped
its keyword alternation in \b. _ is a word character, so \b never fires
between an underscore and a letter — every prefixed spelling walked past a
blocking guard:

HIT   password = "..."          MISS  db_password = "..."
HIT   secret = "..."            MISS  my_api_key = "..."
HIT   api_key = "..."           MISS  STRIPE_SECRET = "..."
HIT   client_secret: "..."      MISS  aws_secret_access_key = "..."

The MISS column is the dominant real-world spelling — snake_case and
SCREAMING_SNAKE in Python, YAML and .env content, which is precisely what gets
pasted into a learning. client_secret hit only because client[_-]?secret is
spelled out as its own alternative; that coincidence disguised the gap, since a
spot check of the obvious names passes.

The prefix-anchored rules (ghp_, sk-ant-, AKIA…, JWT) were never affected.
The hole was in the one rule covering credentials with no recognisable format.

Found by planting an aws_secret_access_key canary in the store immediately
after installing the pre-push hook — the scan exited 0 and reported clean.

The fix

Replace the \b anchors with an explicit non-alphanumeric left boundary plus
flat affix character classes. Flat classes rather than nested quantifiers, so
backtracking stays linear: a pathological 800-character line searches in ~1ms.
The value remains capture group 1, which _is_placeholder depends on.

False-positive check

Widening the name must not cost the placeholder filter its job — the main risk,
since this gates a push. Verified still clean:

• db_password = changeme → filtered as placeholder
• my_api_key = "your_key_here" → filtered as placeholder
• password: x, secret_name = db → no match (value too short / not secret-like)

Tests

Three new cases in tests/test_scan_secrets.py covering the prefixed hits, the
prefixed placeholders, and the intended non-hits. Full suite: 162 tests, OK.

Also: this repo now uses a personal store

The second commit replaces a blunt learnings/ gitignore with personalStoreDir
in .lore.json — the feature built for exactly this. Notes about developing the
plugin stay private, while learnings/ goes back to un-ignored so the plugin's
own repo does not contradict the default every user gets (team store, committed
and shared).

With no published store here, the local guards had nothing left to protect, so
the pre-push hook, the .lore/ script copies and .github/workflows/lore.yml
are dropped. Verified both scripts exit 0 with a message when the store is
absent, so that workflow would have been permanently green without checking
anything — and the .lore/ copies duplicated plugin/scripts/ two directories
away, drifting silently whenever a fix landed in one and not the other (which
already happened once in this branch).