Make the pre-PR gate answerable; open-pr now pushes

[l1a]

Description

Two gates that could not be satisfied from the situation they failed in. Both were hit by hand
while landing #191, and both are fixes rusticprofile already had and retch never received.

just pr ended in a bare read

So only a human at a terminal could answer it. A script, CI job or agent either blocked on a stdin
that would never answer or died without saying why — and that failure reads as the gate refusing
the change, not as a question nobody could hear.

It now takes its answer from PR_CONFIRM, from an interactive stdin, or from piped input under a
ten-second bound, and the failure message names PR_CONFIRM.

It is not a bypass. All four paths still require an explicit y, so this widens who can
answer, not what counts as an answer — and the checklist still has to be answered after each
item is actually checked, not before.

just open-pr did not push

On a never-pushed branch gh pr create has no remote branch to open from, so the recipe printed
"Gate passed" and then exited non-zero — which reads as the gate rejecting work it had just
approved.

It now pushes only when there is no upstream. Pushing unconditionally would make the recipe
silently publish existing commits on a branch that already has one, which is a different and more
surprising act than "put this branch where gh can see it". pre-push still runs just check, so
this cannot publish a branch the gate would refuse — the push is inside the gate, not around it.

Why these existed

They are rusticprofile's 0.0.21 and 0.2.12. Same cross-repo staleness that left the nushell
completion path wrong here for months, and that #191's standard-check now guards for the install
family. The pr/open-pr triad is deliberately not covered by that standard —
templates/justfile-common.just records it as out of scope, because these recipes legitimately
differ per repo (--workspace here, --all-targets in etr, bare in rusticprofile).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Breaking change
• This change requires a documentation update

How Has This Been Tested?

All four confirm paths, in both directions:

case	result
PR_CONFIRM=y	All manual items confirmed? [y/N] y (answered by PR_CONFIRM) → gate passed
no terminal and nothing on stdin	aborts, naming PR_CONFIRM in the message
echo y | just pr	still passes — the pre-existing path is unchanged
echo n | just pr	still refuses — so this is not a bypass

open-pr's push was verified on this PR itself, which is the only honest test for it: the
branch had no upstream when open-pr ran, and that condition cannot be reproduced after the fact.
rusticprofile's 0.2.12 said in as many words that it wanted "a test from a genuinely unpushed
branch".

• just pr green: fmt, clippy --workspace and --features graphics, 69 + 114 + 15 tests,
  man page regenerated at retch 0.6.21, audit advisory-only.

Backup safety

n/a — tooling only, no repository writes.

Checklist

• Style, self-review, comments explaining why in both recipes
• Documentation updated — NOTES.md release entry
• just man re-run after the bump and committed
• No new warnings
• Version bumped 0.6.20 → 0.6.21 (patch)
• No failure mode introduced can degrade silently — the no-stdin path fails loudly and names
  the variable rather than defaulting to yes, and open-pr pushes only when there is no
  upstream rather than publishing commits unasked