Inconsistent context type assertions across API handlers

[fellquent]

I noticed that the handlers under api/v1/marketplace/keys.go and most of api/v1/reversals/reversals.go use checked type assertions when pulling values from the request context:

factory, ok := r.Context().Value(middleware.FactoryContextKey).(repository.Factory)
if !ok {
    render.Errorf(w, r, errors.InternalServerError, "missing factory from context")
    return
}

But the admin handlers and a couple of others skip the check:

factory := r.Context().Value(middleware.FactoryContextKey).(repository.Factory)

The funniest case is reversals.go — createReversals at line 24 does the checked version, and expungeReversal at line 240 in the same file does the bare one.

Here's everywhere the unchecked version is used:

• api/v1/admin/marketplace/marketplace.go — lines 24-25, 88-89, 136-137
• api/v1/admin/keys/keys.go — lines 19-20, 77-78
• api/v1/admin/reversals/reversals.go — lines 19-20, 71-72
• api/v1/admin/users/users.go — lines 17-18
• api/v1/reversals/reversals.go — lines 240-241
• api/v1/users/users.go — line 23

In practice this is fine because the middleware chain guarantees the values are there, so the bare assertions never actually panic. But if someone ever refactors the middleware ordering or adds a new route without auth, the unchecked ones will panic instead of returning a clean error like the checked ones do.

Seems like it'd be a quick pass to make them all consistent with the pattern that's already used in the other handlers.