fix(deploy): wire the Robokassa direct rail into the prod deploy + rollback

The Robokassa credentials reached only the test contour (ci.yaml → TEST_
secrets). The prod-deploy / prod-rollback workflows and write-prod-env.sh
never rendered BACKEND_ROBOKASSA_*, so on prod the shop login was empty and
the direct RUB rail stayed disabled — the PROD_BACKEND_ROBOKASSA_* secrets
went nowhere.

Export the shop login + Password1/Password2 (secrets) and a
BACKEND_ROBOKASSA_TEST flag (a variable, so go-live is a flag flip not a
secret rotation) from both prod workflows, and emit the four ROBOKASSA_*
vars from write-prod-env.sh (the shared deploy/rollback env renderer) so a
rollback keeps the rail up. The compose already maps ROBOKASSA_* →
BACKEND_ROBOKASSA_*. Document the new secrets/variable in the deploy README
and .env.example. Password3 (Robokassa's JWT-invoice API) is unused.

deploy/.env.example

@@ -125,6 +125,17 @@ GATEWAY_VK_APP_SECRET=
 # come from VITE_VK_APP_ID / VITE_VK_ID_REDIRECT_URL above. All three empty disables link.vk.*.
 GATEWAY_VK_ID_CLIENT_SECRET=
 
+# --- Payments: Robokassa (direct RUB rail) ----------------------------------
+# The shop's merchant login + the two pass phrases (Password1 signs the launch request,
+# Password2 signs/verifies the Result callback). An empty login leaves the direct rail off.
+# ROBOKASSA_TEST=1 runs test payments against the shop's TEST pass phrases (no real money);
+# empty/0 is live. Mapped in compose to BACKEND_ROBOKASSA_*; Gitea TEST_/PROD_ secrets, with
+# PROD_BACKEND_ROBOKASSA_TEST a variable so go-live is a flag flip, not a secret redeploy.
+ROBOKASSA_MERCHANT_LOGIN=
+ROBOKASSA_PASSWORD1=
+ROBOKASSA_PASSWORD2=
+ROBOKASSA_TEST=
+
 # --- Gateway anti-abuse ------------------------------------------------------
 # Planted honeytoken bearer value: any request presenting it is flagged — a 24h IP ban
 # where the IP ban is on (prod), logs + a ban metric otherwise (test). Plant the value