Agent notifications endpoint returns 403 for paused deployments

[vsilent]

Description

When a deployment is paused or otherwise non-completed, the agent keeps polling GET /api/v1/agent/notifications?deployment_hash=... and receives 403 responses even though GET /api/v1/agent/commands/wait/{deployment_hash} still succeeds.

Observed nginx log examples:

GET /api/v1/agent/notifications?deployment_hash=deployment_120254c6-598e-47a1-83ca-690840edd906 -> 403
GET /api/v1/agent/commands/wait/deployment_120254c6-598e-47a1-83ca-690840edd906?timeout=10&priority=normal -> 200

This showed up after deployments were paused during proxy/container failures, but the bug is in the server-side authorization/lifecycle handling for agent notifications.

Steps to Reproduce

1. Start a deployment for a project.
2. Pause or fail the deployment (for example, via a port allocation conflict).
3. Let the agent continue its normal polling loop.
4. Observe that /api/v1/agent/notifications?deployment_hash=... returns 403, while /api/v1/agent/commands/wait/... still returns 200.

Expected Behavior

• Agent notification polling should remain authorized for the active deployment hash until the agent is told to stop, or
• the agent should stop polling notifications once the deployment enters a terminal/paused state.

Actual Behavior

The notifications endpoint returns 403 repeatedly, creating noisy logs and inconsistent agent behavior after paused deployments.

Acceptance Criteria

• Add a failing regression test that reproduces the 403 for a paused/failed deployment hash before the fix.
• Add a BDD scenario describing agent polling behavior across in_progress, paused, and error deployment states.
• Make notification polling behavior consistent with the command wait endpoint for the same deployment hash.
• Prevent repeated 403 noise after a deployment transitions into a paused/error state.