GHSA-r9g5-7q8j-958c

### Summary

When `secureEnabled=true`, FUXA `1.3.0-2773` still allows guest and invalid-token requests to read project, alarms, and scheduler APIs.

### Details

In secure mode, requests with no token or an explicitly invalid token were still able to access protected read endpoints.

Confirmed behavior:

- guest `GET /api/project` returned `200 OK` - invalid-token requests to `/api/project` also returned successful responses containing project data - guest and invalid-token requests also returned `200 OK` on: - `/api/alarms` - `/api/scheduler`

Relevant code paths identified during analysis:

- `server/api/jwt-helper.js` - `verifyToken()` converts missing-token or invalid-token states into guest context instead of rejecting the request - `server/api/projects/index.js` - `server/api/alarms/index.js` - `server/api/scheduler/index.js`

These handlers accepted the guest context and returned sensitive data in secure mode.

### PoC

Tested only against isolated local lab instances under the original tester's control. No production, customer, shared, or third-party systems were involved.

Reproduction:

1. Start FUXA `1.3.0-2773`. 2. Set `secureEnabled=true`. 3. Send unauthenticated requests to: - `GET /api/project` - `GET /api/alarms` - `GET /api/scheduler?id=test` 4. Observe `200 OK` responses. 5. Send the same requests with an explicitly invalid `x-access-token` value. 6. Observe the same successful responses.

The exact HTTP requests and local PoC script used for confirmation can be provided upon request.

### Impact

This is an authentication/authorization weakness in secure mode.

Impact includes:

- project metadata disclosure - alarms disclosure - scheduler information disclosure - assistance in reconnaissance/follow-on attacks

Operators who believe secure mode protects these APIs are impacted.