watcher/snapshot: isSensitivePath misses OpenSSH default key names id_ecdsa, id_dsa, and *_sk FIDO variants

[justrach]

Problem

The sensitive_names exact list in both isSensitivePath copies (src/watcher.zig:1200, src/snapshot.zig:1328) covers id_rsa and id_ed25519 but misses the other ssh-keygen default basenames: id_ecdsa, id_dsa, and the FIDO variants id_ecdsa_sk / id_ed25519_sk. Inside ~/.ssh/ the directory rule catches them, but a key copied into a repo — deploy/id_ecdsa — is indexed and readable while deploy/id_rsa is blocked. Same class as the #585-adjacent secrets pass (*.env suffix, .git-credentials).

Failing Test

test_mcp.zig — fails on current release tip:

test "issue-588: isSensitivePath blocks all OpenSSH default private key names" {
    const keys = [_][]const u8{ "id_ecdsa", "id_dsa", "id_ecdsa_sk", "id_ed25519_sk" };
    for (keys) |k| {
        try testing.expect(watcher.isSensitivePath(k));
        try testing.expect(snapshot_mod.isSensitivePath(k));
    }
    try testing.expect(watcher.isSensitivePath("deploy/id_ecdsa"));
    // negatives — names that merely start like a key must stay indexable
    try testing.expect(!watcher.isSensitivePath("id_map.zig"));
    try testing.expect(!watcher.isSensitivePath("identity.ts"));
}

Expected

All six ssh-keygen default private-key basenames are blocked everywhere, matching the existing id_rsa/id_ed25519 handling.

Fix

Add the four names to the exact list in both copies (they all start with i, so the fast-path branch already routes them to the exact-match check). The #528 parity test keeps the copies honest.

[justrach]

Fixed in b368119 — isSensitivePath blocks id_ecdsa, id_dsa, and *_sk FIDO key names (PR #605 later deduplicated the two copies into one impl). On release/0.2.5825, suite 808/808; ships with 0.2.5825.