chore(hardening): widen sensitive-file coverage and apply it to Grep/Glob

[devGregA]

Problem

The sensitive-file policy that guards the file tools was narrow in two ways:

1. It matched by basename, covering .env*, id_rsa / id_ed25519 / id_ecdsa, credentials, and .aws|.gcp/credentials. But private keys and cloud credential files are routinely given local names — deploy_key, work-cluster.json, sso-cache.json — which no basename list can predict. Common credential files (.git-credentials, .netrc, .npmrc, .docker/config.json, kubeconfig) were not covered either, nor was the CLI's own ~/.kimi-code/config.toml, which holds the configured provider API key.
2. Grep and Glob opted out entirely, passing checkSensitive: false. So a search could return the contents of files that Read/Write/Edit refuse to open.

What changed

• Directory-based rules (SENSITIVE_DIRECTORY_SEGMENTS): anything under .ssh, .gnupg, .aws, .azure, .kube, .config/gcloud, or the CLI's own credentials dir is sensitive regardless of filename.
• Deliberate exemptions, so this doesn't over-block: *.pub, known_hosts, .ssh/config (host aliases) and .aws/config (region settings) stay readable. The config exemption is per-directory on purpose — .kube/config is the credential, so it stays blocked.
• Added by name: .git-credentials, .netrc / _netrc, .npmrc, .pypirc, .dockercfg, .docker/config.json, kubeconfig, .kimi-code/config.toml.
• Grep and Glob now use checkSensitive: true, matching the other file tools.
• Applied to both engine copies of the policy (agent-core and agent-core-v2).

Testing

• New cases in both suites: credential directories with arbitrary filenames are sensitive; the named credential files are sensitive; and the exemptions (known_hosts, .ssh/config, .aws/config, *.pub) still read.
• Verified as real tests: with the two policy files reverted, exactly the 4 new positive tests fail.
• Full regression across both engines: 9006 passed (agent-core + agent-core-v2). No suite depended on Grep/Glob skipping the check.
• One unrelated pre-existing flake surfaced in hostFsWatchService.test.ts (a timing-sensitive fs-watcher test); it passes on re-run and has no reference to this policy.
• oxlint and tsc --noEmit clean for both packages.

Note on scope

This PR covers which paths are treated as sensitive. It does not change how paths are canonicalised — that guard is still lexical (no realpath), so a symlink inside the workspace is still resolved by name only. Closing that is a separate change with a real design decision behind it (the path-access module is pure and synchronous, while realpath is async through the host FS abstraction), so it is deliberately not bundled here.

Checklist

• Problem explained above (fork-local hardening; no upstream issue).
• Tests added that prove the change works.
• Changeset added (minor — more paths are refused than before).
• No doc update needed.