feat: show the CAP's required libraries, package identity and components (v3.5.16)

The Import component (JC VM spec 6.6) is now exposed by /api/cap-info and
rendered in the CAP analysis box:

- imports: the libraries the CAP is linked against with the export-file
  versions and the number of distinct constant-pool references (6.7),
  displayed as "name >= version" (a card resolves an import only with the
  same major and a minor >= the recorded one, 4.5.2).  Standard names come
  from the AID table; each gets a family label (Oracle JavaCard / ETSI SIM
  2G / ETSI UICC / 3GPP USIM-ISIM / GlobalPlatform) and, for
  javacard.framework, a Java Card SDK release hint derived from the local
  Oracle SDK kit corpus (jc211..jc305u4 exports; unknown versions stay
  unhinted).  Vendor/applet AIDs stay bare.
- Header package flags (Table 6-4: int / exports / applet package) and the
  optional JC 2.2 package_name (absent in all CAP 2.1 files).
- components: every archive entry in load-file order with its size and
  share of the load file (including the Directory/Export entries capmem
  does not parse); the sizes sum to load_file_bytes.
- The PWA box leads with "Requires: ..." when imports exist, keeps the
  compiled-against line (Java Card hint + CAP format), the package/applet
  identity, the import details (family, refs, AID) and the component
  breakdown in Details; a memory-only response still renders.

Tests: Python +2 (imports/flags/name/components; header flags + package
name) with the synthetic CAP builder extended; frontend +2 renderer cases
(unknown AIDs, no-import responses) plus jcAidNorm/jcAidFamily tests; the
jcAidNorm extraction added to the ram/scp81 harnesses.
Help EN/RU, docs/api.md, AGENTS.

591 frontend / 473 Python green; version 3.5.16; sw simple-v269.

docs/api.md

@@ -348,6 +348,11 @@ used for installation.
   "memory": {
     "package_aid": "AA1902BC226001",
     "applet_count": 1, "applets": ["AA1902BC226001"],
+    "imports": [{"aid": "A0000000620101", "minor": 0, "major": 1, "refs": 6},
+                {"aid": "A0000000090005FFFFFFFF8912000000", "minor": 11, "major": 1, "refs": 7}],
+    "flags": {"raw": 4, "int": false, "export": false, "applet": true},
+    "package_name": null,
+    "components": [{"name": "Header", "size": 20}, {"name": "Method", "size": 433}],
     "class_count": 3, "method_count": 12,
     "code": {"method_component": 850, "load_file": 1234},
     "nvram": {"static_image": 12, "array_init": 4, "install_objects": 100,
@@ -360,6 +365,18 @@ used for installation.
 }
 ```
 
+`imports` are the libraries the CAP is linked against (JC VM spec §6.6,
+the Import component), each with the export-file version recorded in the CAP
+and the number of distinct constant-pool references to it (§6.7; a linked but
+unreferenced package is 0).  A card resolves an import only when the resident
+package has the **same major** version and a **minor ≥** the recorded one
+(§4.5.2), hence the `name >= version` display.  `flags` decodes the Header
+package flags (Table 6-4: `0x01` uses `int`, `0x02` exports an API, `0x04`
+applet package); `package_name` is only present in JC 2.2+ headers (CAP 2.1
+files have none); `components` lists the archive entries in load-file order
+(each size includes the component's tag and size header, so the sizes sum to
+`load_file_bytes`).
+
 `code.load_file` is the concatenated load file (all components) - the
 package image the card stores, our proxy for the GlobalPlatform Card Spec
 v2.3.1 Table 11-48 "non-volatile code" minimum memory requirement; the