fix: Answer the console reads to the configured owner

[nfebe]

The user directory, a single user and the engagement report ran behind authentication alone. Any account with a token could read every user on the deployment. Every other endpoint here already answered to the configured owner.

[sourceant]

Code Review Summary

🔒 This release closes an authorization gap in the admin console reads. The user directory (users), single user lookup (user), and the engagement report (metrics) previously ran behind authentication alone, so any account holding a token could enumerate every user on the deployment. All three now call the controller-level owner check, and authorizeOffers was generalized into authorizeConsole so the offers endpoints share the same guard. AdminController::user now accepts the Request as its first parameter to perform that check, and a feature test asserts the three endpoints return 403 when authorization denies. Version bumped to 0.2.1 with a matching CHANGELOG.md entry.

🚀 Key Improvements

• src/Http/Controllers/AdminController.php: metrics, users, and user now enforce the configured-owner check, matching the rest of the console surface
• src/Http/Controllers/AdminController.php: authorizeOffers renamed to authorizeConsole, with the docblock updated to state the guard is applied in the controller so a host swapping the request class cannot drop it
• tests/Feature/AdminAuthorizationTest.php: new test covers the directory, single-user, and report endpoints returning 403 under denying authorization
• CHANGELOG.md and composer.json: 0.2.1 released with a description of the tightened access

[sourceant]

Review complete. No specific code suggestions were generated. See the overview comment for a summary.