Continuing the backend token-check sweep: found factory-api.php (systems/30-tech/apps/Factory/) hardcoded the same dead old admin token as its OWN internal validation check ($TOK = 'yttcom-admin-d60283...'), rejecting the current token outright. Confirmed via direct test: current token returned {error:unauthorized}, old dead token returned status:ok. This is a 4th instance of the same migration gap but a different shape -- the prior 3 fixes this session (android.html, win/server/android-scripts.php) were CLIENT pages calling out to an API with a stale token; this one is the API endpoint ITSELF validating against a stale token internally. Fixed by migrating to the same shared backend/config/auth-lib.php pattern already proven working in apps/Inventory/inventory-api.php (fixed 08/22/26 by Server[40], msg 1118/4054) -- replaced the hardcoded $TOK exact-match check with require_once auth-lib.php + cai_require_token($token), which accepts either a current active token from tokens.json or an authenticated browser session cookie. Also checked systems/30-tech/laboratory/apps-hub.html (the frontend hub's 'Applications Reference' link) which calls lab-api.php and inventory-api.php with the same old hardcoded token as a CLIENT value -- confirmed this is NOT a bug: both of those APIs only accept the old token (lab-api.php rejects the current token outright, inventory-api.php accepts both via its own auth-lib.php fix) -- left apps-hub.html untouched since changing its token would break it against lab-api.php specifically.