fix: enforce Sanctum API token abilities on Api controllers

[morcen]

What was broken

Jetstream's API-token feature (Features::api()) was recently enabled (#218), so users can now create personal access tokens and restrict them to specific abilities (create, read, update, delete) via the API Tokens UI. However, auth:sanctum only verifies that a token is valid — it never checks what the token is scoped to do. None of EndpointController, EventController, DeliveryController, or WebhookController (under app/Http/Controllers/Api) called tokenCan() or used any ability: middleware.

This meant a token a user deliberately restricted to "read" (e.g. handed to a third-party integration) silently retained full create/update/delete access anyway — it could create/update/delete endpoints and events, trigger arbitrary webhook deliveries, and read all delivery data, regardless of what abilities were selected in the UI.

What changed

• Added a small authorizeAbility() helper on the base App\Http\Controllers\Controller that aborts with a 403 unless $request->user()->tokenCan($ability).
• Called it at the top of every action across the four API controllers, mapping each action to the ability that already exists in the API Tokens UI:
  • index/show/stats → read
  • store → create
  • update/regenerateSecret → update
  • destroy → delete
  • WebhookController::trigger → create (creates new deliveries)
  • WebhookController::retryDelivery → update (mutates an existing delivery)

Session-authenticated requests (the Inertia dashboard, and tests using actingAs()) are unaffected: Sanctum wraps session-authenticated users in a TransientToken, whose can() always returns true, so this only restricts requests actually made with a real, ability-scoped personal access token.

• Added tests/Feature/ApiTokenAbilityEnforcementTest.php covering that a read-only token is rejected on every mutating endpoint/event/delivery/webhook action, that a token with the right ability succeeds, and that session-authenticated requests are unaffected.
• Updated ApiEventNameUniquenessScopeTest and DeliveryRetryRateLimitTest to use Sanctum::actingAs() for the specific cases where a test authenticates as a second user against a Sanctum-guarded route within the same test method. auth:sanctum's guard caches its resolved (and TransientToken-wrapped) user for the rest of the test process once it first authenticates, so a later plain actingAs() call for a different user object bypassed that wrapping — previously invisible because nothing checked abilities, now surfaced by this fix. This is Sanctum's own documented pattern for this exact test scenario.

Testing

• vendor/bin/pint --dirty — clean
• php artisan test — full suite passes (240 passed, 4 pre-existing skips, 0 failures)

Fixes #53