Files view: the change-details modal shows the full file path (v2.4.2)

- the modal header showed only the flat name (EF_ICCID, 4F09); it now shows the
  path built from data already available: the tracker's DF identity named via
  KNOWN_FIDS (MF, DF_GSM_ACCESS, DF_TELECOM, …), 'ADF' for the current
  application (7FFF), DF_CHILDREN for DF-qualified EF names (4F52 →
  EF_KcGPRS) and the EF.DIR labels for AID-selected applications —
  e.g. `MF/EF_ICCID (2FE2)`, `ADF/EF_IMSI (6F07)`,
  `DF_GSM_ACCESS/EF_KcGPRS (4F52)`, `AID A00000015141434C00/4F09`
- exposed as `path` in the change-details payload and in the files entries
  (the timeline rows keep the short name — they have no room)
- the colour legend (changed / newly observed / never observed) moved below
  the two hex views
- tests: `_file_path` cases (MF, ADF, DF-qualified EF, AID with and without an
  EF.DIR label, FID-as-name) plus the payload field, and the Node modal test
  asserts the path header and that the legend follows the views
- v2.4.2; SW cache simtrace-analyser-v68

README.md

@@ -194,11 +194,14 @@ trace-wide timeline of file operations — every **Read**, **Update** and
 **Changed on card** row shows the same file name as the Map view, and clicking
 a row jumps to the APDU in the trace.  Rows that carry a recorded change (a
 card-side change, or an update that wrote or first observed bytes) also offer
-**Details**: a modal showing 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, plus the changed/new byte counts and the APDU reference.
+**Details**: a modal showing the full file path (`MF/EF_ICCID (2FE2)`,
+`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.
 
 The images come from `GET /api/sessions/<id>/files/image?key=…&change=…` and
 are reconstructed from the current image by undoing the later changes