fix: keep a hand-edited packet TAR in the SCP80 send (v3.6.21)

The plain "Send to Card" path refreshed the whole preset right before
sending (spRefreshFromPreset -> cardsApply -> cardsApplyFields) and
re-applied the preset's slot TAR - so a TAR typed for a push/link trigger,
an applet OTA message or the HTTP OTA admin params was silently replaced by
the preset's ISD TAR (the pack buttons for those sources deliberately leave
the TAR manual; the help even said so).

- spRefreshFromPreset(selId, keepTar): the plain send passes keepTar, so
  the form's TAR survives; the counter, keys and SPI are still re-read.
- selecting a card preset, ramApplyCard and the chain packs still set the
  TAR; the RAM operations keep the preset's ISD TAR by design.
- spParams()/getRamSpParams() normalise the TAR (strip/upper/pad to 6);
  only the preview padded before, a short TAR went to the server raw.
- help EN/RU clarified, cards_counter/ram tests updated, sw simple-v294.

652 frontend / 499 Python green; version 3.6.21.

frontend/tests/ram.test.js

@@ -499,6 +499,11 @@ test('getRamSpParams reads the computed SPI2 byte, not the base select', () => {
 	assert.ok(/spi2: document\.getElementById\('sp-spi2-hex'\)/.test(fn), fn);
 });
 
+test('getRamSpParams normalises the packet TAR to three bytes', () => {
+	const fn = extractFunc(html, 'getRamSpParams');
+	assert.ok(/tar:[\s\S]*?padEnd\(6, '0'\)\.slice\(0, 6\),/.test(fn), fn);
+});
+
 test('ramListingSpi2 requests the SMS-submit PoR for the listing queries', () => {
 	// Apps (40) and ELF (20/10) listings can exceed the ENVELOPE response;
 	// with SPI2=0x01 the card answers actual_response_sms_submit and the data