v3.19.2: the three-status-words disambiguation (envelope SW vs por.sw)

The script author read por.sw as the envelope SW, so a por.sw expectation
on an applet's own TAR failed with (none).

- docs/test-scripts.md: a 'The three status words (envelope SW / PoR
  status / R-APDU SW)' table in the authoring section - where each one
  comes from, the script field and the report row - plus a cross-reference
  from the por check paragraph; help EN/RU 8.9 points at it.
- a failed por.sw check on a response_type: 'raw' decode carries the check
  detail 'the response is application data - an applet's own TAR has no
  R-APDU SW; assert it with data' (the PWA renders check details).
- the runner's log prints APP DATA=<hex> (no R-APDU SW) for application
  responses instead of the misleading R-APDU SW=(none) data=...; the
  compact/scripting lines are unchanged.
- the step editor's custom-PoR block gets a one-line hint about the same.
Tests: 821 frontend + 730 Python; sw cache simple-v391.

frontend/tests/testscripts.test.js

@@ -250,6 +250,9 @@ test('the SCP80 step form renders the format select and the custom PoR fields',
 	assert.match(body, /<option value="custom" selected>/);
 	assert.match(body, /id="test-f-porstatus" value="por_ok"/);
 	assert.match(body, /id="test-f-por-sw" value=""/);
+	// the block explains where PoR SW comes from (the applet-TAR confusion)
+	assert.ok(body.includes('R-APDU SW inside a remote-management'), body);
+	assert.ok(body.includes('leave SW empty'), body);
 	// the pre-built packet source has no format select (the wrapper applies
 	// to a C-APDU only)
 	_testEditStep = { type: 'action', kind: 'scp80', params: { source: 'sp', sp: 'AABB' } };