v3.25.0 review: the DF-tree ARR resolution walk-up

The live card references 6F06 from MF-tree files (MF/7F20/6F07 ->
8B 03 6F06 14), but the resolver compared only the path's first
segment: the reference fell back to the ADF.USIM copy instead of the
file's own DF copy (ISO 7816-4 5.4.3.3 / TS 102 221 9.2.7 walk-up) -
masked on this card only because all four copies are byte-identical.

- The server reads the DF.TELECOM and DF.GSM copies too (MF/7F10/6F06,
  MF/7F20/6F06 - TS 51.011), best effort.
- fcpArrRules resolves by the file's DF chain (own DF first, then
  walking up to MF); a reference with no copy in the chain resolves
  only when a single candidate exists, otherwise it stays silent.
- The implicit form prefers the file's DF copy (6F06), walking up to
  the MF copy (2F06).

Tests: the DF copy wins over the ADF copy; two candidates outside the
chain stay unresolved; a single one resolves; the implicit walk-up;
the server reads the DF-tree paths.  879 frontend + 858 Python;
sw cache simple-v424.

docs/api.md

@@ -1403,8 +1403,8 @@ is not initialized.
 
 Returns the card's cached **EF.ARR copies** — the access-rule files the FCP
 security attribute DO `'8B'` references (ISO 7816-4 Table 25).  The copies
-are read once per card session when a card is equipped (`MF/2F06` and
-`ADF.USIM/6F06`, best effort) and served from memory, so this endpoint
+are read once per card session when a card is equipped (`MF/2F06`,
+`MF/7F10/6F06`, `MF/7F20/6F06` and `ADF.USIM/6F06`, best effort) and served from memory, so this endpoint
 performs no card I/O; a disconnect clears the cache, and an `EF.ARR` write
 through `/api/write` refreshes it.