[Feature Request]: Unify `auth` controller governance

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/EnAccess/micropowermanager/blob/main/CONTRIBUTING.md) for this project, if it exists.
- [x] I agree to follow the [Code of Conduct](https://github.com/EnAccess/micropowermanager/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://github.com/EnAccess/micropowermanager/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

In our (backend) code base there is currently no single point of truth for auth governance.

- Some routes define a `auth` middleware in their route definition, for example [`solar-home-systems`](https://github.com/EnAccess/micropowermanager/blob/main/src/backend/routes/api.php#L385-L391)
- Other routes, don't for example [`e-bikes`](https://github.com/EnAccess/micropowermanager/blob/main/src/backend/routes/api.php#L392-L398)

How does this even work?

It does because the [`UserDefaultDatabaseConnectionMiddleware`]( https://github.com/EnAccess/micropowermanager/blob/main/src/backend/app/Http/Middleware/UserDefaultDatabaseConnectionMiddleware.php) effectively re-implements the auth-gate logic again, by calling `$guard = auth('agent_api');` and `$guard = auth('api');` hardcodedly.

This creates ambiguity and confusion amongst developers. There should be one and only one plays that defines the auth structure.

### Proposed Solution

Please use the route definition as source of truth for auth-gates. Every route should define their correct `auth` middle ware

For example like so

```php
Route::group(['prefix' => 'e-bikes', 'middleware' => 'auth:api'], static function () {
Route::get('/', [EBikeController::class, 'index']);
Route::post('/', [EBikeController::class, 'store']);
Route::get('/search', [EBikeController::class, 'search']);
Route::get('/{serialNumber}', [EBikeController::class, 'show']);
Route::post('/switch', [EBikeController::class, 'switch']);
});
```

This seems to be the most idiomatic approach in Laravel world. That let Laravel’s auth system flow naturally through middleware + policies/gates.

Then, change `UserDefaultDatabaseConnectionMiddleware` to apply it's logic based on the available `auth` middleware, instead of hardcoding routes.

### Alternatives Considered

N/A

### Additional Information

_No response_