Serve a shop's own staff to the till, so the built-in PINs can retire

The terminal shipped with three names and three PINs compiled into it. Same
three on every install, readable by anyone with the APK, and permanent —
nothing anywhere could replace them.

`/pos/staff` answers with the people the back office says may ring a bill at an
outlet, and the same list rides down with the session so a till is ready to
trade the moment it signs in. The terminal writes them over its own and
deactivates whatever it had, which is what actually kills the seeded logins.

Two sources are unioned because the schema has two and neither is complete.
`tenantstaffs` is the table built for this and holds 12 rows on the entire
platform; `app_users.locationid` is where staff actually ended up. Either alone
returns nothing for almost every shop.

The endpoint takes no location parameter. The answer carries PINs, so the
outlet comes from the caller's token and a request without one is refused
whatever POS_AUTH_REQUIRED says — a till must not be able to ask who works at
the shop next door.

Rows with no PIN are dropped rather than sent: a name on screen nobody can sign
in as reads as a broken terminal rather than as an unfinished setup. Duplicate
PINs are dropped too, keeping the first — live data has 1234 on eleven accounts
and 1111 on nine, and two people sharing one would make the till attribute a
bill to whichever row it checked first.

The PIN travels in the clear over TLS, deliberately. Four digits are
brute-forceable in microseconds however they are wrapped, so hashing here would
buy the appearance of strength and not the substance — while costing something
real, since the terminal salts every PIN with its own salt before storing it
and could never verify a hash computed here. A PIN is shift attribution, not a
security boundary; the boundary is the session token.

Verified against live data, and it says the fallback still matters: outlet 1135
— the one the POS actually uses — has zero staff, and the only staff row found
anywhere is a delivery rider on PIN 1111.

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

models/pos.go

@@ -281,4 +281,46 @@ type PosSession struct {
 	// gets a list of one, so the till has no special case: it shows a picker
 	// when there is a choice and skips it when there is not.
 	Locations []PosLoginLocation `json:"locations"`
+
+	// The people who may ring a bill at the chosen outlet.
+	//
+	// Sent with the session so a terminal is ready to trade the moment it signs
+	// in, rather than needing a second call before the first customer. May be
+	// empty — most tenants have no staff recorded yet — and the terminal has to
+	// cope with that rather than treat it as a failure.
+	Staff []PosStaffMember `json:"staff"`
+}
+
+// PosStaffMember is one person who may ring a bill at an outlet.
+//
+// Distinct from the account that signs the *terminal* in. The sign-in says
+// which shop this till belongs to; this says who is standing at it, and it is
+// what gets stamped on a bill as `cashiername` and settled against at the end
+// of a shift.
+//
+// The PIN travels in the clear, over TLS, and that is a considered choice
+// rather than an oversight. A four-digit PIN is brute-forceable in microseconds
+// whatever it is wrapped in, so hashing it here would buy the appearance of
+// strength and not the substance. What it would cost is real: the terminal
+// salts every PIN with its own random salt before storing it, so a hash
+// computed here could never be verified there without inventing a shared
+// scheme and keeping two codebases agreeing about it for ever.
+//
+// The honest framing is that a PIN is *shift attribution*, not a security
+// boundary. The boundary is the session token — which is what stops a till
+// reaching another tenant's books at all. The PIN decides which of the people
+// already inside a shop gets credited with a sale, and the terminal still
+// stores it hashed at rest.
+type PosStaffMember struct {
+	Userid   int    `json:"user_id"`
+	Fullname string `json:"full_name"`
+	Role     string `json:"role"`
+	Pin      string `json:"pin,omitempty"`
+	Status   string `json:"status,omitempty"`
+}
+
+// PosStaffResponse answers a request for an outlet's people.
+type PosStaffResponse struct {
+	Locationid int              `json:"location_id"`
+	Staff      []PosStaffMember `json:"staff"`
 }