Inconsistent authorization enforcement pattern across endpoints

[umerfaruk]

Summary

Authorization is enforced three different ways depending on the endpoint, with no consistent default-deny baseline.

Details

• Pipeline attributes: `[LibraryAuthorize(...)]` on commands, `[LibraryAuthorize(...)]`/`[AuthorizeAdmin(1)]` on queries.
• Manual in-handler checks, e.g. `GetAccountByIdQueryHandler` (src/Inshapardaz.Domain/Ports/Query/Account/GetAccountByIdQuery.cs:20-24) has the attribute commented out and replaced with a hand-written `if` check.
• Repository-level filtering by `accountId`, e.g. `GetBookByIdQuery` relies on `bookRepository.GetBookById(libraryId, bookId, accountId, ...)` to filter by visibility rather than any handler-level check.
• Some endpoints (see Identify and implement proper authorisation and authentication #1) have no check at any layer.

Impact

This inconsistency is exactly how #1 happened — there's no single place to look to confirm an endpoint is protected, and it's easy to ship a new endpoint without realizing it needs an explicit authorization step.

Suggested fix

Pick one default-deny pattern (e.g. always require the pipeline attribute, with an explicit opt-out for genuinely public queries) and consider a test/lint that fails if a `LibraryBaseCommand`/`LibraryBaseQuery` handler has no authorization attribute.