test: cover the auth paths the design decisions depend on

[NidaKarim]

Found while reviewing coverage on the auth layer after submission. No production code changes — tests only.

The gap

JwtStrategy had 0% unit coverage, and more importantly the behaviour that its design exists for was untested anywhere:

validate() re-reads the user from the database rather than trusting the token claims, so a deleted or demoted user loses access on the next request rather than whenever their token happens to expire.

That is the main argument for accepting a per-request database read — and nothing demonstrated it.

What's added

Unit — src/auth/strategies/jwt.strategy.spec.ts

• looks the user up by the token subject
• returns the shape that becomes request.user, without passwordHash
• trusts the database role over the token claim
• rejects a token whose user no longer exists

E2E — test/services.e2e-spec.ts

• GET /auth/me returns the caller (endpoint previously had no coverage)
• a still-unexpired token whose user has been deleted is rejected
• a role change takes effect without re-issuing the token

That last one logs in as a viewer, gets 403 on a write, promotes the user to admin in the database, then reuses the same token — which still carries "role":"viewer" — and gets 201.

Coverage

File	Before	After
jwt.strategy.ts	0%	100%
auth layer overall	36%	49%

jwt-auth.guard.ts remains at 0% unit coverage. Its @Public() branch is exercised end to end by every login, so I left it rather than write a test that only restates the guard's implementation.

Suites

45 unit (was 41) · 59 e2e (was 55). Lint clean.