Feature request: PermissionGranted hook event to complement existing PermissionDenied

Summary

The hook system currently has PermissionDenied (fires when a user denies a tool request) but no corresponding PermissionGranted event. The missing event makes it impossible to detect the moment a permission is approved — only tool completion (PostToolUse) is available as a proxy.

Problem

PermissionRequest fires before the dialog is shown. PostToolUse fires when the tool finishes. For short commands the gap is small, but for long-running commands (test suites, builds, dev:full, etc.) there can be minutes between when the user approves and when PostToolUse fires. During that window there is no way to know whether the permission is still pending or has already been granted.

Concrete example: A chime notification system built on hooks — start a countdown on PermissionRequest, cancel it on PostToolUse/PermissionDenied. Works correctly for fast commands, but fires false-positive chimes during long-running approved commands because PostToolUse hasn't fired yet.

Requested

Add a PermissionGranted hook event that fires at the moment the user approves a permission request, before or as the tool begins executing.

Combined with the existing PermissionDenied, this would give the hook system complete coverage of permission lifecycle:

| Event | Fires when |
|---|---|
| PermissionRequest | Before dialog is shown |
| PermissionGranted | ✨ User approves ← missing |
| PermissionDenied | User denies (already exists) |
| PostToolUse | Tool completes successfully |
| PostToolUseFailure | Tool fails |

Alternative

A single PermissionResolved event covering both outcomes (with the decision in the payload) would also work and might be cleaner than two separate events.

Workaround

Currently working around this by using a longer initial delay (2 minutes) before the first chime, hoping most commands complete before then. It's a guess, not a signal.