docs(onprem): safer ddorch certificate handling in the Helm upgrade render

[Maffooch]

Follow-up to #16301, from a review of the Helm upgrade and install pages it changed.

Fixed

• Pre-upgrade render (upgrade guide, step 6). The previous text copied the ddorch private key out of a ConfigMap into the working directory, and rendered into /tmp.
  • The step now works in a private directory (mktemp -d, with umask 077).
  • It reads the three certificates back from the release's stored values with helm get values -o json and jq. That works because values passed with --set-file are kept in the release, which I checked against a test release.
  • It checks that each file is non-empty with test -s.
  • For an Argo CD-managed release, or one whose values do not hold the key, it falls back to the chart's own objects. That fallback works on both chart layouts: the key in the <fullname>-orch-certs-configmap ConfigMap, or in a <fullname>-orch-certs Secret. It also covers ddorch.tls.existingSecret, where the key is not copied at all. I tested both the values path and the fallback (ConfigMap and Secret layouts) against test releases.
  • The step ends by deleting the directory, which holds the key and the render.
• Object and Secret names. These follow the chart's full name, not the release name. The full name is the release name when it contains dojopro, otherwise <release>-dojopro, and tenantPrefix or fullnameOverride change it. The upgrade step and the admin-password section now say so, and show how to list the exact names.
• Chart source. Step 6 offered the extracted zip as $CHART, then ran helm pull regardless. The pull is now only for the registry path.
• Wording. Removed the duplicated sentence about the ddorch certificate files. The link labelled "on-premise upgrade notes" now says what it is: the general on-premise upgrade procedure.
• Install guide notes.
  • The bootstrap-script note no longer names the ConfigMap, so it is right whichever object holds the key.
  • The FIPS note drops a release number that could not be verified.
  • The cosign note names cosign 2.x's --insecure-ignore-tlog=true for networks without internet access. I checked that flag against cosign's own verify-blob reference for 2.0.0 and 2.4.1.

Not changed: translated pages

The translated copies of these pages (de, es, fr, it, ja, pt-br, zh-hans) did not get the #16301 fixes and still carry the older commands. Under docs/TRANSLATIONS.md, English is the source and translations are regenerated from it by the translation pipeline, so this PR does not edit them. The next translation refresh should pick up #16301 and this PR.

Checks

• npm run build -- --environment development and hugo --minify --gc --config config/production/hugo.toml in docs/: both exit 0 with no warnings or errors.
• Internal links and anchors on the changed pages resolve against the built site.

🤖 Generated with Claude Code