TRACK H ITEM 5, THE LAST LOGIN INSTRUMENT. Evidence, 28 July 2026.

THE REPORT: a design partner said she had logged in and the control plane showed
"never signed in".

THE EVIDENCE THAT SHE WAS RIGHT, from the control plane:
  batwood@igotozarks.com     sessions=2   active=2  last_login=NULL
  joseph.w.anady@gmail.com   sessions=135 active=134 last_login=2026-07-21 (STALE by a week)
  patriciacox6@aol.com       sessions=1   active=1  last_login=NULL   <- her login, 28 Jul 08:04
  tallen282005@gmail.com     sessions=6   active=6  last_login=NULL
  trutle973@hotmail.com      sessions=1   active=1  last_login=NULL
Four of five accounts held real ACTIVE sessions while the screen said none of
them had ever signed in.

THE CAUSE, internal/modules/auth/service.go line 902:
    _, _ = db.Exec(ctx, `SELECT auth_touch_last_login(, )`, userID, orgID)
The $1 and $2 placeholders were MISSING FROM THE SOURCE, almost certainly
stripped by an edit made through a shell that expanded the dollar signs away.
Postgres rejected it as a syntax error on EVERY sign in, and both return values
were discarded, so it failed silently for weeks.

RULED OUT FIRST, each by direct test rather than by reading:
  The function exists with the right signature and works: calling it as the
    postgres superuser stamped the row.
  The app role HOLDS execute: has_function_privilege = true.
  Row level security is not the cause: the function is SECURITY DEFINER owned by
    missionmatch_migrator, which has BYPASSRLS.
  Calling it as the APP ROLE with literal ids stamped correctly.
  One intermediate test of mine was INVALID and is recorded as such: passing
    subselects as the app role returned NULL under RLS, so the function's NULL
    guard returned early and the result looked like a failure that was not one.

THE FIX: placeholders restored, and the failure is now LOGGED. It is still not
allowed to fail the login, because recording a sign in is bookkeeping and denying
entry over bookkeeping would turn a reporting defect into an outage. Zero rows is
also caught explicitly, because Postgres does not treat it as an error and it is
exactly what a silent no op looks like.

PROVEN ON STAGING, two real logins through the live API:
  before  desk.admin@fg-talent.test  last_login=NULL
          patriciacox6@aol.com       last_login=NULL
  after   desk.admin@fg-talent.test  last_login=2026-07-28 16:19:27.020857-05
          patriciacox6@aol.com       last_login=2026-07-28 16:19:27.413547-05

POSITIVE CONTROL, as the protocol requires. EXECUTE was revoked from the app role
to break the stamp deliberately:
  the login still returned 200, which is correct, bookkeeping must not deny entry
  last_login stayed NULL, so the break was real
  and the server SAID SO: 1 ERROR line,
    "auth: last login stamp failed, the accounts screen will understate this sign in"
Restoring the grant made the next login stamp again at 16:19:54. The instrument
now reports its own failure, which is the whole repair.

PRODUCTION HISTORY BACKFILLED from auth_sessions, the authoritative record of who
actually signed in. UPDATE 5. A diagnostic call of mine had also written a FALSE
timestamp for Patricia (16:16, when her real session was 08:04); the backfill
corrected it rather than leaving my own artifact in the data.
  batwood@igotozarks.com    2026-07-27 15:17:12
  joseph.w.anady@gmail.com  2026-07-28 11:51:42
  patriciacox6@aol.com      2026-07-28 08:04:16
  tallen282005@gmail.com    2026-07-27 14:42:49
  trutle973@hotmail.com     2026-07-27 16:51:29

STILL TO DO: the code fix is on staging only. Production runs the old binary and
will keep failing to stamp NEW logins until a Track H production deploy is
approved. The backfill above repaired history, not the mechanism.