paperWidth: '112mm' throws immediately for every print job — invalid columns value

[GomdimApps]

Any print job built with paperWidth: '112mm' fails right away, before any
content is sent — not just images or a specific element type, the encoder
constructor itself throws.

Steps to reproduce

const printer = new WebEscposPrinter({ paperWidth: '112mm' })
await printer.printReceipt({ content: [{ type: 'text', value: 'hi' }] })
// or:
await printer.printReceipt({ paperWidth: '112mm', content: [{ type: 'text', value: 'hi' }] })

Actual result

Rejects with:

Error: The width of the paper must me either 32, 35, 42, 44 or 48 columns

(thrown by @point-of-sale/receipt-printer-encoder's ReceiptPrinterEncoder
constructor)

Expected result

A receipt is built and printed, same as 58mm/80mm.

Root cause

config.ts's PAPER_WIDTH_SPECS maps '112mm' to columns: 56:

export const PAPER_WIDTH_SPECS: Record<PaperWidth, { columns: number; imageMaxWidth: number }> = {
  '58mm': { columns: 32, imageMaxWidth: 384 },
  '80mm': { columns: 42, imageMaxWidth: 576 },
  '112mm': { columns: 56, imageMaxWidth: 832 },
}

But the installed @point-of-sale/receipt-printer-encoder (^3.0.3) only
accepts a fixed set of column counts:

if (![32, 35, 42, 44, 48].includes(this.#options.columns) && !this.#options.embedded) {
  throw new Error('The width of the paper must me either 32, 35, 42, 44 or 48 columns')
}

56 isn't in that list, so new ReceiptPrinterEncoder({ columns: 56, ... })
throws unconditionally, inside buildReceiptBytes() — which means
printReceipt() fails for every job that uses paperWidth: '112mm',
regardless of content. 58mm (32 columns) and 80mm (42 columns) are both
in the valid set, so they're unaffected.

Also worth noting: 112mm's spec was already flagged as an estimate, not
hardware-verified (see docs/notes/02-paperwidth-scales-columns-and-imagemaxwidth.md),
unlike 80mm which was cross-checked against real hardware.

Suggested fix

Pick a columns value for 112mm from the encoder's accepted set
(32/35/42/44/48) — 48 is the closest to the current estimate. Would also
be worth re-deriving imageMaxWidth consistently and, ideally, verifying
against real 112mm hardware while at it, same as 80mm was.

Regression test

This is now pinned (as an expected-failure) by
test/Printer/ReceiptBuilder.pdf417.test.ts's "paperWidth" suite — once
fixed, that test should be flipped from assert.rejects to
assert.doesNotReject.