Explain grant-mismatch asks with a prompt notice

[TheGreatAxios]

Summary

• When a standing grant covers a shell command but a pre-grant guard still forces an ask, the prompt carries a notice naming the guard reason (--force use, uncontained worktree destination, sensitive path, or path outside the workspace)
• --force=<value> spellings count as force in the worktree policy, so the inline-value skip can no longer swallow force intent

Verification

• bun run typecheck, bun run build, and the full bun run check suite pass (7141 pass, 0 fail)
• New gate tests assert real prompted requests carry the exact notice text; new policy tests pin the --force=<value> ask and the --no-force pass-through

Fixes CL-6824

[linear-code]

CL-6824

[TheGreatAxios]

Audit: Approve, no code change requested. Grant-mismatch notices name the guard reason without changing match semantics: every covered-but-guarded case still asks and stays deniable, only the prompt gains the why, and treating --force= as force intent is the safe direction. File-for-later: the startsWith("--force=") prefix over-matches in principle, since any --force= (including empty or garbage values real git would reject with exit 129) is treated as force. Harmless today because ask is the safe direction, but worth a precise matcher if the flag grammar ever grows.