feat: integration path for lager-resolver (warehouse-label generator)

[strausmann]

What problem does this solve?

I run a separate self-hosted project lager-resolver (https://git.strausmann.de/strausmann/lager-resolver) that owns the warehouse-location catalog: rooms, shelves (IKEA Kallax/Billy/Alex), Samla boxes, and the QR-coded canonical IDs printed on every label (HH-AK-KX10-F0203 etc.). It already generates the full print-job CSVs (print_jobs_p750w.csv, print_jobs_ql820.csv) from the same catalog the resolver uses for QR-code lookup.

Today the workflow is: download CSV → feed into P-Touch Editor or brother_ql_web manually. That's fine for bulk runs but tedious when a single label gets damaged and needs a reprint. I want the resolver to push individual reprints (or a selected subset) directly to the Hub so I can stand in front of the broken label, scan its parent QR, tick the affected child(ren), hit print, and walk away.

Proposed solution

Two viable shapes — favoring B for keeping the Hub generic and avoiding coupling to lager-resolver-specific concepts.

A) New "lager-resolver" integration tab (analog to Snipe-IT/Grocy/Spoolman).
The Hub fetches the layout payload from lager-resolver via its API when a print is triggered. Symmetric with the existing integrations, but adds a new App-lookup target and ties the Hub to the resolver's API shape.

B) Generic "raw batch print" endpoint with inline fields (preferred).
Extends the planned POST /api/print/{printer_id}/batch from ADR-0013 with an integration: "raw" mode (or a sibling endpoint) where the item carries the pre-rendered field data inline — no upstream lookup, no Hub-side fetcher needed:

{
  "items": [
    {
      "integration": "raw",
      "layout_id": "<uuid>",
      "quantity": 1,
      "fields": {
        "line1": "HH-AK-KX10-F0203",
        "line2": "Kallax 4x4 Fach S2 R3",
        "qr_data": "https://lager.strausmann.cloud/loc/HH-AK-KX10-F0203"
      }
    }
  ]
}

The Hub validates the layout, fills the named fields into the template, runs it through the existing queue. No new fetcher, no per-integration code, no token storage for yet another upstream. Any external CSV/script generator (not just lager-resolver) can use it too.

Alternatives considered

• C) Status quo — CSV download. Works. Done. Already exposed on the resolver's /catalog page. But the round-trip via P-Touch Editor / brother_ql_web UI sucks for single-label reprints.
• D) Extend the Snipe-IT integration with locations.* lookups. Workable because my locations ARE imported into Snipe-IT with the combined-name format. But it couples lager-resolver-specific semantics into the Hub's Snipe-IT integration code and only works for users who feed locations into Snipe-IT in the first place. Doesn't generalize.
• E) Smuggle the print payload inside an existing integration's lookup_id. Hack. Not worth listing in detail.

Suggested area

• API
• App lookup (Snipe-IT / Grocy / Spoolman) — or a sibling "raw" mode that lives next to it

Notes

• Same maintainer on both sides, so this is mostly a cross-repo coordination note.
• The resolver already has the data ready (CSV generators in internal/generator/) and a selection UI is being added on its side that maps cleanly to the proposed payload.
• Once the Hub side has the endpoint, the resolver gains an LAGER_HUB_URL env var and the existing "Ausgewählte CSV"-button gets a sibling "An Hub senden"-button.

Contribution

• I'm willing to submit a PR for this feature
• I can test it on my hardware (PT-P750W + QL-820NWBc)