Files view: the PBR's SFI relations reach the APDU decode — and survive DF hops (v2.7.8)

- the PBR SFIs were learned only by the tracker; the message decode's
  per-channel SFI map still did not know them, so the SEARCH RECORD addressed
  by SFI 2 after the PBR read showed "SFI 2, unknown file" (the reported
  case: session 193, 5.434 s — the PBR read at 4.451 declared ADN 4F3A/SFI 2)
- database._advance_state now parses an EF_PBR record it sees (a READ
  RECORD's data or an UPDATE RECORD's body) and merges its FID+SFI pairs
  into the channel's SFI map, so SFI-addressed SEARCH/READ resolve without
  the file's own FCP
- the learned relations are cached per DF for the session: the live trace
  leaves DF_PHONEBOOK for DF_TELECOM (SELECT 7F10/6F06) and comes back, and
  the DF change used to rebuild the map from the static table only, dropping
  the PBR's pairs — the re-entry now merges the session cache
- verified on session 193: the SEARCH at 5.434 s (SFI 2) now resolves to
  4f3a (EF_ADN), as do the later ones (31.562/253.475/279.874 s)
- tests: the DB-level case — a PBR read, an excursion to DF_TELECOM and back,
  then an SFI-addressed SEARCH asserting the declared file; 538 Python +
  76 Node tests
- PWA_VERSION/pyproject/version.py 2.7.8, SW cache simtrace-analyser-v88

frontend/index.html

@@ -3386,7 +3386,7 @@ function onSearchChange() {
 }
 
 // ──────────────────── Versioning ────────────────────
-const PWA_VERSION = '2.7.7';
+const PWA_VERSION = '2.7.8';
 const MIN_SERVER_VERSION = '2.3.0';
 
 function parseVersion(v) {