Change details: no filler past a short file, no offsets for a single row (v2.7.3)

- the hex views padded every line to 16 bytes with '--', so a 2-byte file
  looked like it was missing data; the row now ends at the known file/record
  length (from the FCP — hexImageRows gained the size parameter), while '--'
  still marks bytes *inside* the file that were never observed (an unknown
  length keeps the old row padding, nothing better is available)
- the offset column is shown only when a view spans more than one row — a
  four-hex-digit 0000 above two bytes was noise
- the legend lists only the marks actually rendered: 'never observed' is gone
  from a short/fully-observed view, and 'newly observed' when nothing was
  first observed (the summary line still counts both)
- tests: pure hexImageRows cases (the 2-byte file, a 9-byte record with an
  unobserved tail, the unknown-size fallback) plus two renderFileDiff cases
  pinning the missing filler/offset and the trimmed legend; 527 Python +
  75 Node tests
- README/README_RUS describe the new hex-view behaviour;
  PWA_VERSION/pyproject/version.py 2.7.3, SW cache simtrace-analyser-v83

README.md

@@ -219,10 +219,12 @@ card-side change, or an update that wrote or first observed bytes) also offer
 `ADF/EF_IMSI (6F07)`, `DF_GSM_ACCESS/EF_KcGPRS (4F52)`, `AID …/4F09` — the DF
 named from the EF.DIR labels when known) and the affected unit — the whole
 file, or the single record that changed — **before and after** the change, as
-hex views (16 bytes per row, never-observed bytes drawn as `--`) with the bytes
-that changed highlighted in one colour and the bytes the operation first
-observed in another, the changed/new byte counts, the APDU reference and the
-colour legend below the views.
+hex views (up to 16 bytes per row — a shorter file/record ends its row there
+instead of padding with `--`, and the offset column only appears when a view
+spans more than one row) with the bytes that changed highlighted in one colour
+and the bytes the operation first observed in another, the changed/new byte
+counts, the APDU reference and a colour legend below the views that lists only
+the marks actually shown.
 
 The images come from `GET /api/sessions/<id>/files/image?key=…&change=…` and
 are reconstructed from the current image by undoing the later changes