fix(barcode): validate EAN-13/8, UPC-A, ITF-14 before bwip-js — front…

[simonabler]

…end + backend

Problem: bwip-js threw opaque internal errors (bwipp.ean13badLength, bwipp.ean13badCheckDigit) that escaped as unhandled 500s with a Content-Type mismatch warning. The frontend had no format validation and fired requests on every keystroke regardless of digit count.

Backend (barcodes.service.ts):
New private validateStandardText(type, text) method called at the top of
both toPng() and toSvg() before bwip-js is invoked:
EAN-13: must match /^\d{12,13}$/, check digit verified if 13 digits given
EAN-8: must match /^\d{7,8}$/, check digit verified if 8 digits given
UPC-A: must match /^\d{11,12}$/, check digit verified if 12 digits given
ITF-14: must match /^\d{13,14}$/
CODE128 / CODE39 / PDF417 / DATAMATRIX: no pre-validation (bwip handles)
Throws BadRequestException with a clear, human-readable message.
Private eanCheckDigit() / eanCheckDigitValid() helpers implement the
standard Luhn-style EAN weight (odd×1, even×3).

Frontend (barcode-editor-item.component.ts/.html):
New barcodeTextValidator(getType) ValidatorFn mirrors the backend rules.
Applied via addValidators() on the text control; re-runs when type changes.
Invalid requests are blocked (EMPTY returned from switchMap).
Validation error shown inline below the text input (is-invalid + feedback).
API errors from catchError are also surfaced via errorMsg.