Cleanup: result_formatter has stray leading space in code ' FUEL_REM' and number→string type bugs

[kevinelliott]

Summary

Two small but real defects in lib/utils/result_formatter.ts:

1. Leading space in code: ' FUEL_REM'

remainingFuel emits a formatted item whose code field starts with a space:

static remainingFuel(decodeResult: DecodeResult, value: number) {
  decodeResult.raw.fuel_remaining = value;
  decodeResult.formatted.items.push({
    type: 'fuel_remaining',
    code: ' FUEL_REM',          // <-- leading space, doesn&#39;t match the surrounding style
    label: 'Fuel Remaining',
    value: decodeResult.raw.fuel_remaining.toString(),
  });
}

Every other code in this file is a clean upper-snake-case identifier (FOB, FB, FUEL_OUT, …). Downstream consumers grouping by code will see " FUEL_REM" as a separate bucket from "FUEL_REM". The leading space is almost certainly a typo.

Fix: code: 'FUEL_REM'.

2. sequenceNumber / sequenceResponse assign a number to a string field

Per DecoderPluginInterface.DecodeResult, each formatted.items[*] has value: string. But these two formatters assign the raw number directly:

static sequenceNumber(decodeResult: DecodeResult, value: number) {
  decodeResult.raw.sequence_number = value;
  decodeResult.formatted.items.push({
    type: 'sequence',
    code: 'SEQ',
    label: 'Sequence Number',
    value: decodeResult.raw.sequence_number,   // <-- number, not string
  });
}

static sequenceResponse(decodeResult: DecodeResult, value: number) {
  ...
  value: decodeResult.raw.sequence_response,   // <-- number, not string
}

This is inconsistent with every other formatter (which calls .toString() or wraps in a template literal) and quietly violates the declared value: string type. Strict TS settings would catch this; with the current settings it slips through.

Fix: value: decodeResult.raw.sequence_number.toString() (or `${...}`), and the same for sequence_response.