feat(harness): aliro-bench-test --step-up + INSTALL.md install-recovery notes

Adds a PC/SC verification path for Step-Up Milestone 1 so M1 can be
validated against a personalized card without depending on Nucleo /
X-CUBE-ALIRO bring-up. Verdict run on J3R452 04555A4A0B2190 with M1
CAP installed: AUTH1 OK (3.4s), EXCHANGE 0xC9 OK, ENVELOPE 0xC3 OK
with response decrypting under StepUpSKDevice to the spec 0xA0 ack.

- crypto.py: derive_step_up_session_keys (HKDF parity with
  AliroCrypto.deriveStepUpSessionKeys)
- transaction.py: expose step_up_sk on TransactionResult
- step_up.py: verify_step_up_m1 -- SELECT 5502 + GCM-encrypted
  C9/C3 round-trip, IVs per StepUpApplet (0x00*8 || counter
  reader-side; 0x00*7 || 0x01 || counter device-side)
- cli.py: --step-up flag on aliro-bench-test
- tests: stdlib-RFC-5869 cross-check on the new KDF (122/122 green)
- INSTALL.md: fix multi-place PKG AID typo (missing 02 version byte),
  document partial-install recovery, document package-static
  credential store (aliro-personalize success !=> 5501/5502 installed)

applet/INSTALL.md

@@ -38,7 +38,7 @@ java -jar gp.jar --info                          # confirm reader sees the card
 # Multi-applet CAPs: load the package once, then create each instance.
 # --create needs the instance AID, the applet class AID (same as instance
 # here), and the package AID (printed by --load).
-PKG=A0000009094454414C49524F
+PKG=A0000009094454414C49524F02
 java -jar gp.jar --load applet/target/aliro-applet-j3r180.cap
 java -jar gp.jar --create A000000909ACCE5501   --applet A000000909ACCE5501   --package $PKG
 java -jar gp.jar --create A000000909ACCE5502   --applet A000000909ACCE5502   --package $PKG
@@ -50,6 +50,21 @@ specify the right one with --[applet]"`, and `--create AID` without
 `--applet`/`--package` fails with `"Need --[package, pkg] and --[applet]
 or --[cap]"`.)
 
+**Partial install / recovery**: if a `--create` call fails mid-sequence
+(card got reset, USB hiccup, RF dropout), the package stays loaded. Just
+re-run the failed `--create` — no need to redo `--load` or the earlier
+`--create` calls. The package only needs `--delete` + `--load` again if
+the package itself is in a bad state.
+
+**Credential store is package-static**: keys and the Access Document
+written via `aliro-personalize` live on a static class shared by all
+three applets. Personalization only requires `ACCE559901` to be
+SELECTABLE; `5501` and `5502` can be `--create`d after personalize ran
+and they'll see the same credentials. (Note: `aliro-personalize`
+returning "Personalization complete" only confirms `559901` accepted the
+writes — always cross-check `gp --list` to confirm `5501` and `5502`
+are also SELECTABLE.)
+
 Default GP test keys (`404142434445464748494A4B4C4D4E4F`) are tried
 automatically. For non-default keys, pass `--key <hex>` to every command.
 
@@ -61,10 +76,10 @@ Three applets get registered, one CAP:
 | `A0000009 09 ACCE 55 02`         | `StepUpApplet`         | Aliro STEP_UP phase (spec; scaffold only ATM)|
 | `A0000009 09 ACCE 55 99 01`      | `PersonalizationApplet`| DT-internal provisioning channel             |
 
-All three share the package AID `A0000009 09 4454414C49524F` (CSA RID +
-ASCII "DTALIRO"). JavaCard requires applets in one CAP to share the
-package's RID, hence the proprietary AID for personalization is also
-under the CSA RID with a non-spec PIX (`99 01`).
+All three share the package AID `A0000009 09 4454414C49524F 02` (CSA RID
++ ASCII "DTALIRO" + version byte). JavaCard requires applets in one CAP
+to share the package's RID, hence the proprietary AID for personalization
+is also under the CSA RID with a non-spec PIX (`99 01`).
 
 ## Verify
 
@@ -184,7 +199,7 @@ then the package:
 java -jar gp.jar --delete A000000909ACCE5501
 java -jar gp.jar --delete A000000909ACCE5502
 java -jar gp.jar --delete A000000909ACCE559901
-java -jar gp.jar --delete A0000009094454414C49524F
+java -jar gp.jar --delete A0000009094454414C49524F02
 ```
 
 Then `--load` + the three `--create` commands above to reinstall the