Disabled QR codes continue to redirect through the public scan endpoint

Problem/Motivation

The public endpoint /api/qr-code/{uuid} checks whether a QR code exists and has expired, but does not check its status field. Consequently, disabled codes continue redirecting visitors to their configured destinations.

This also affects account cancellation using user_cancel_block_unpublish: the cancellation hook disables the user’s QR codes, but those codes remain usable through the public endpoint.

Steps to reproduce

1. Create an enabled QR code with a valid destination and no expiration.
2. Visit its public scan URL as an anonymous visitor and confirm that it redirects.
3. Edit the QR code, clear its Enabled status, and save.
4. Visit the same scan URL again.

Actual result

The disabled QR code still redirects to its destination.

Expected result

Disabled QR codes return HTTP 404 without redirecting. Enabled, unexpired codes remain accessible to anonymous visitors. Enabled but expired codes continue returning HTTP 410, and unknown UUIDs return HTTP 404.

Proposed resolution

Update QRRestResource::get() to check the entity’s status immediately after UUID lookup, before checking expiration or constructing the destination. Use translated public error messages without exposing administrative details.

Preserve anonymous scanning without requiring administrative entity-view permissions. Review the resource’s unused access() method and remove it if confirmed unused by the REST route pipeline.

Regression coverage

Extend QRRestResourceFunctionalTest.php to cover:

- Disabled codes, including disabled codes that are also expired.
- Disabling and re-enabling after a successful scan.
- Codes disabled through account cancellation.
- Anonymous access to enabled, unexpired codes.
- Existing 404 and 410 behavior.

Assert the redirect status and Location header directly instead of relying on the final HTTP 200 after following redirects.