feat(TE-22637): add threshold flags to upload-pdf

[shrinishLT]

What

upload-pdf gains threshold support with one way in per level:

Level	How
build-level (every PDF in the upload)	--approvalThreshold <n> / --rejectionThreshold <n>, or the config file
per-PDF	the config file only — pdf.thresholds, keyed by resolved PDF name

smartui upload-pdf ./invoices --buildName release-42 --config config.json

{
  "web": { "browsers": ["chrome"], "viewports": [[1920, 1080]] },
  "approvalThreshold": 2,
  "rejectionThreshold": 5,
  "pdf": {
    "approvalThreshold": 1,
    "thresholds": { "invoice.pdf": { "approval": 0, "rejection": 4 } }
  }
}

upload-pdf now accepts -c --config and reads the same config.json exec uses: the existing top-level approvalThreshold/rejectionThreshold apply to PDFs too; the pdf block is new and optional. One file serves web and PDF, which is the shape a Jenkins pipeline with one mixed PDF directory needs.

Resolution — client-side, per file, like the web path

The CLI resolves one final {approval, rejection} per uploaded PDF — pdf.thresholds[name], else the build-level value (flag → pdf.* → top-level) — and posts only the complete thresholds map. That mirrors snapshotQueue.ts resolving per snapshot; there is one precedence rule, in one place (src/lib/pdfThresholds.ts). ?? throughout, so an explicit 0 is sent, never dropped. The raw per-call form fields stay on the endpoint for API/SDK callers; the CLI doesn't send them.

Fails before any file is uploaded when a pdf.thresholds key matches no uploaded file (or --pdfNames name), or a flag isn't numeric; the server still validates range, band (rejection > 0 && approval > rejection), and use_default_thresholds as the last line.

Compatibility — strictly additive

pdf joins the schema's anyOf so a PDF-only config is valid for upload-pdf; every other command keeps the "web or mobile required" rule in ctxInit, so an existing file behaves identically for exec. Unknown keys inside pdf are rejected. Verified against the built CLI: web-only, web+thresholds, web+pdf and pdf-only files on both commands; typo and out-of-range values fail with the schema messages.

Behaviour when nothing is set

Unchanged: no flags, no pdf block, no top-level thresholds → nothing new is sent → project settings apply, exactly as today.

Verified on the pdf-thresholds dev env (2026-09-09, 02:21–02:34 IST)

dev-tests/TE-22637/run.sh, DB-verified, against smartui-rendering-service#1264 + dotlapse-event-service#2913:

Case	Result
legacy (platform='pdf') and Omni projects, config above	rows invoice 0/4, contract 3/5, report 1/5 on both tables — explicit 0 preserved
nothing set	rows NULL/NULL
unknown name in pdf.thresholds	fails before upload, names it; no build created
--approvalThreshold 6 --rejectionThreshold 5	rejected, inverted band
--approvalThreshold 5 --rejectionThreshold 0	accepted (rejection=0 = never auto-reject)
--approvalThreshold 101	rejected, field named
two uploads, same --buildName, different groups via --pdfNames	one build, a1–3 @2/5 and c1–3 @7/9
same names re-uploaded to a build	400 naming the files; build survives

Not in this PR

• exitOnError: false on this task means a server 400 prints red and exits 0 — same as exec/upload; deliberately unchanged (RFC §7.4).
• tsc --noEmit fails on the untouched tsconfig.json (TS5110) — pre-existing; tsup is the build and passes.

Server: LambdatestIncPrivate/smartui-rendering-service#1264 · DES: LambdatestIncPrivate/dotlapse-event-service#2913 · RFC: LambdatestIncPrivate/internal-docs#2963 · Ticket: TE-22637

🤖 Generated with Claude Code

https://claude.ai/code/session_01QbnKfTzhr64osinPevTmVG

[sushobhit-lt]

Good news first: this does not repeat the --sync no-op from #558. I traced every read site back to the ctxInit whitelist in src/lib/ctx.ts:292-294 and the keys match exactly; field names, types and the 0-100 range agree with the server parser in smartui-rendering-service#1264, and an explicit 0 survives end to end.

The risk here is error handling rather than wiring — three comments below.