Let an admin create till staff from the console, through the same code

An admin sets a shop up from a browser; a supervisor adds a cashier at the
counter. Both had to be possible, and only the second one was.

So the console gets createposuser / updateposuser / getposusers /
deleteposuser, under both /v1/web/tenants and /v1/mob/tenants — calling the
same service methods `/pos/users` calls. Not a parallel implementation: a
supervisor created from a browser is the same row, with the same PIN rules, the
same duplicate check and the same identity-column allocation, as one created at
a till. Two paths writing one table is precisely how the two stop matching, and
this codebase already had that happen once.

configid is inferred rather than asked for. It is a number nobody looks up, it
varies per tenant — 1087's accounts are spread across 1, 6 and 15 — and getting
it wrong creates somebody who cannot sign into the portal their colleagues use
and is invisible to half the platform's queries.

/posroles is served rather than left to the console to hardcode. A console that
knew supervisor was 7 would be wrong the day that changed and would have no way
to find out.

The outlet is the real difference between the two doors. A terminal proves it
with a signed token; the console asserts it, and is checked against the tenant
before anything is written. That is weaker, and it is worth being plain about:
these mint till credentials on an unauthenticated request, exactly like every
other route in the /v1/web and /v1/mob groups, because there is no auth
middleware on the web API at all. Documented as the weakest point in the design
and flagged to move behind a session guard once the console can hold one. The
terminal routes are untouched by it.

Proven in a rolled-back transaction against live data: the console creates a
supervisor at 1135, that supervisor signs in by PIN with can_manage_staff true,
the till's /pos/staff sees them alongside the two created at the counter, and
0451, 1234 and a duplicate PIN are each refused with the same message the
terminal gives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

routes/posroutes.go

@@ -73,4 +73,37 @@ func RegisterPosRoutes(api fiber.Router, f *facade.Facade) {
 	// broker rather than posting it here.
 	pos.Get("/health/terminal", f.PosController.TerminalHealth)
 	pos.Get("/health/location", f.PosController.LocationHealth)
+
+	registerPosStaffConsoleRoutes(api, f)
+}
+
+// Till staff, managed from the web console rather than from a counter.
+//
+// Under `/web` and `/mob` rather than `/pos`, because the callers are the back
+// office and the daily app — neither holds a terminal session, and putting them
+// behind the terminal guard would lock out the very screen an admin uses to set
+// a shop up in the first place.
+//
+// They run the same service calls as `/pos/users`. A supervisor created here is
+// the same row, with the same rules applied, as one created at a till.
+//
+// The outlet is asserted rather than proved, which is the real difference and
+// the weaker half: a terminal signs its outlet, a console just names one. It is
+// checked against the tenant before anything is written, and these should move
+// behind a session guard as soon as the console can hold one — until then, this
+// mints till credentials on the strength of an unauthenticated request, exactly
+// like every other route in this group.
+func registerPosStaffConsoleRoutes(api fiber.Router, f *facade.Facade) {
+	for _, group := range []string{"/v1/web/tenants", "/v1/mob/tenants"} {
+		g := api.Group(group)
+
+		// Served rather than hardcoded, so a console offering the choice does
+		// not have to know that supervisor is 7.
+		g.Get("/posroles", f.PosController.WebPosRoles)
+
+		g.Get("/getposusers", f.PosController.WebListPosUsers)
+		g.Post("/createposuser", f.PosController.WebCreatePosUser)
+		g.Put("/updateposuser", f.PosController.WebUpdatePosUser)
+		g.Delete("/deleteposuser", f.PosController.WebDeletePosUser)
+	}
 }