Fix #391: let admins show/edit/delete containers they don't own

[Om-singhaI]

Issue

Fixes #391 — 404 for non-owned container as Admin. An admin can see other users' containers in the "all containers" list, but selecting Edit on one they don't own renders an empty form; the network tab shows a 404 on GET /api/v1/sites/:siteId/containers/:id.

Root cause

The list route (GET /containers) already resolves admin access correctly via resolveUsernameFilter (user=* returns every owner for admins). But the three single-container routes hard-scoped their lookup to the requester:

where: { id: ..., username: req.session.user }

So an admin can list a container they don't own, yet GET/PUT/DELETE /:id all 404 on it — hence the empty edit form.

Change

Add a small containerOwnerWhere(session) helper that mirrors the list route's ownership logic:

• admin → {} (no owner constraint)
• everyone else → { username: session.user }

and apply it to the show, update, and delete routes.

• create-a-container/routers/api/v1/containers.js (+16/-3)

Preserved behaviour

• Site scoping is unchanged — the existing node.siteId checks (and the PUT route's inner join on siteId) still confine access to the current site, so this does not let an admin reach another site's containers.
• Non-admins are unaffected — they remain restricted to containers they own on every route.

Testing

This package has no test harness and the app requires Postgres + Proxmox + LDAP to run end to end, so I verified this by inspection and node --check. The change is a targeted authorization scoping fix. Happy to add tests if you'd like a harness introduced, or to adjust if admins should be limited to a subset of these operations (e.g. view-only vs. full manage).