The pool showed only "Assigned today" — no indication of WHO had the
stop — and the PO number was inert text, so an operator chasing a
supplier had to open the order to find the paperwork.
Driver name
order_items.drv_id is a PB record id, so it is useless on screen.
The page already loads the user list into `driversById` to pre-fill
the assign dialog; that same map now rides onto the row, so the
badge reads "Assigned to Ruan" and a second line spells it out with
the scheduled date for column scanning. Filtering the pool by driver
name now works too, since the name is on the row.
The badge keeps its old date-only wording when no name resolves (the
lookup is best-effort) and never renders the raw id — "assigned to
krpyec9l" is not actionable. Unassigned rows ignore a stale drv_id.
PO download
The PO number links to
`/api/v1/purchase-orders/{id}/pdf?download=1`, matching the order
detail page. `version` is deliberately omitted so the link always
resolves to the CURRENT document — the one the supplier was sent.
Customer rows only. `source: "stock"` rows hang off a
`stock_purchase`, a different collection: the purchase-orders PDF
route is keyed on `purchase_orders` records and would 404 on a stock
id. Those POs live as PB files under `stock_purchases/{id}/` with no
download route yet, so their number stays plain text rather than
shipping a broken link.
Tests: 6 new cases covering driver naming, the unresolved-name
fallback, ignoring a stale driver on unassigned rows, driver search,
and refusing to match a PB id as if it were a name.