feat: a Kanban card names the dials its next run will use (#84)

[Lexus2016]

Closes the Kanban Visibility half of #84.

The defect

A card rendered one badge, tk.sess_model. It was wrong twice over:

1. Blank on a task that had never run. A board of freshly created cards said nothing about the model/effort/engine the user had just picked in the create modal.
2. Silent about a bot's model, which overrides the session's inside the runner — so a card assigned to a bot named the wrong model.

The fix

kbRunBadges() in public/kanban.html mirrors server.js/startTask exactly:

model  = taskBot?.model || session?.model || task.model || 'sonnet'
effort = task.effort
engine = task.run_engine === 'subscription' ? 'subscription' : 'api'

• bot_model is joined in getTasks, not looked up client-side. The board fetches its bot roster only when a modal opens, so kbBots is [] at first paint; a client-side lookup would render one model before the user touched anything and a different one afterwards. The join carries AND b.deleted_at IS NULL because stmts.getBot does — without it a card advertises the model of a bot the runner will refuse to load.
• Effort and engine render only when they are NOT the default. auto effort and the api engine are what nearly every card carries; a badge on all of them is noise in a footer already holding the project, schedule, session and retry badges. An unknown effort is shown verbatim rather than dropped — a bad stored dial reaching the run is exactly what a silent badge would hide.
• The chain card (renderChainCard) is untouched. A chain has no bot and no per-task engine.

Cost

• Schema: none. One additive LEFT JOIN + one column on an existing SELECT; /api/tasks gains a key, which is backward-compatible.
• i18n: no new keys — reuses tb.model / tb.effort / tb.engine / effort.* / engine.sub, all already present in en/fr/he/ru/uk.
• Perf: the join is on tasks.bot_id against a table with a handful of rows; the board already polls this endpoint.
• Risk: the card and the runner live in different files. test/kanban-run-badges.test.js therefore pins the runner's own expression as source text as well as the helper's behaviour — a reorder in startTask fails the suite instead of silently making every card lie.

Deliberately NOT in this PR

The rest of #84 — a per-task provider (Codex/Gemini/…), dynamic option catalogs, task templates — is answered in a comment on the issue. In short: the Kanban worker parses claude's stream-json; external agents reach the studio only via /api/delegate + the terminal, which is fire-and-forget with no turn budget, no retry and no session resume. Wiring one into taskWorker is a new execution backend, not a dropdown.

Verification

$ npm test
...
asar-helpers: 9 passed, 0 failed
EXIT=0

$ node test/kanban-run-badges.test.js
40 passed, 0 failed

Live, against a real server booted on a throwaway APP_DIR:

server booted -> stmts.getTasks prepared without error
POST /api/bots -> 200 {"id":"reviewer","label":"Reviewer",...,"model":"opus",...}
POST /api/tasks -> 200 200
{"title":"plain task","bot_id":null,"bot_model":null,"sess_model":null,"model":"haiku","effort":"high","run_engine":"subscription"}
{"title":"bot task","bot_id":"reviewer","bot_model":"opus","sess_model":null,"model":"haiku","effort":null,"run_engine":null}
ASSERT bot_model present on the bot task: PASS (opus)

So the first card renders haiku · High · Subscription, the second opus — which is what each will actually run with.

🤖 Generated with Claude Code