[SECURITY] Enforce authorization for admin-only meeting pages, APIs, and attachments

## Location of the Security Issue
* **File/Feature:** app/blueprints/main.py, app/blueprints/api.py, app/models.py, app/templates/event.html, app/templates/admin/dashboard.html, tests/blueprints/test_main.py, tests/blueprints/test_api.py
* **Version:** Latest

## Description of the Security Issue
Admin-only meetings are hidden from normal users on the home page and meeting list, but the same authorization requirement is not enforced when meeting resources are accessed directly by URL. An anonymous or non-admin user who knows or guesses a meeting ID can access the meeting page, related API data, and potentially uploaded attachments.

Authentication and authorization are correctly used elsewhere in the application, but hiding a meeting from a list does not prevent direct access to its underlying routes.

## Affected Endpoints
* `/event//` - exposes meeting details, minutes, attendees, and attachment information
* `/api/event/attendees//` - exposes attendee usernames
* `/api/event/notes//` - exposes meeting minutes
* `/api/event/state//` - exposes meeting state and confirms that the meeting exists
* `/api/event/attachments//` - exposes attachment names and internal file paths
* `/uploads/` - serves uploaded files without verifying that the requester can access the associated meeting

## Steps to Reproduce
1. Log in to a local app instance as an administrator
2. Create an admin-only meeting
3. Add an attendee, meeting minutes, and an attachment
4. Record the meeting ID
5. Log out or open a private browser window
6. Visit `/event//` directly
7. Observe that the admin-only meeting information is displayed
8. Visit the affected API endpoints using the same meeting ID
9. Observe that attendee, minutes, state, and attachment information is returned without administrator authorization
10. Visit the predictable attachment URL and observe that the file can be accessed directly

## Intended Functionality
Admin-only meeting resources should require:
* A check that the requested meeting exists
* A check of the meeting’s `admin_only` value
* Normal authentication and administrator authorization when `admin_only` is enabled
* Consistent authorization across meeting pages, APIs, and attachment downloads
* A `404` or `403` response for unauthorized requests
* Attachment downloads authorized through their database records instead of only a filename
* API responses that do not expose internal filesystem paths

Preferably a `404` might be used to prevent knowledge of whether or not a private meeting/attachment exists

## Existing Support
Admin-only meetings are already filtered from the home page and meeting list for anonymous and non-admin users. This existing visibility logic can be moved into a reusable authorization helper and applied consistently to the meeting page, API endpoints, and attachment downloads.

---

## Acceptance Criteria & Solution Requirements
*To close this issue, the following must be met:*
- [x] 1. Admin-only meeting pages cannot be accessed by anonymous or non-admin users through a direct URL
- [x] 2. All affected meeting API endpoints enforce the same authorization requirements
- [x] 3. Public meetings remain accessible as intended
- [x] 4. Attachment downloads verify access to the associated meeting
- [x] 5. Guessing an attachment filename cannot bypass meeting authorization
- [x] 6. API responses no longer expose internal filesystem paths
- [x] 7. Missing and unauthorized resources return a consistent `404` or `403` response
- [x] 8. Authorization logic is centralized to reduce the chance of future endpoints missing the check
- [x] 9. Tests cover anonymous, normal-user, and administrator access for pages, APIs, and attachments
- [x] 10. Documentation reflects the access guarantees for admin-only meetings