FR: `jj status` should support `-r` flag

[zygoloid]

Is your feature request related to a problem? Please describe.
I wanted a quick and succinct list of the files edited in a particular jj revision. So I ran jj status -r xy, thinking that should obviously work because the working copy isn't special in jj. But it didn't -- jj status has no flag to specify the revision.

Describe the solution you'd like
jj status -r $REV should work, and should give ~the same output as jj edit $REV; jj status; jj undo, but without the disk churn.

I'd change the heading from "Working copy changes:" to something like "Revision $REV changes:" and change the footer from

Working copy  (@) now at: abc...
Parent commit (@-)      : def...

to something like

Selected revision: abc...
Parent commit    : def...

but otherwise keep the output the same.

Describe alternatives you've considered

jj show --name-only
Probably the best alternative. But: uses different formatting, lacks the added / modified / deleted marker and color coding (maybe these can be addressed with a template). And mostly: requires learning a second command to do the same thing.

jj edit $REV; jj status; jj undo

But this is slow, churns the disk, and feels like the kind of thing that you should never have to do when using jj.

jj edit $REV --no-integrate-operation
jj status --at-operation $OPERATION

Does what I want, other than misleading output talking about @ and the need to manually copy-paste the operation ID from one command to the other (or to parse output that does not look like it was intended to be machine-readable).

[joyously]

I don't think it belongs there, as the status command is for repo status.
But the status help clearly says

Note: You can use jj diff --summary -r <rev> to see the changed files for a specific revision.

[PhilipMetzger]

There's already a PR for this, although I agree with Joy #8749 (see Martins comment in there).

[zygoloid]

Almost all of the jj status output (including all the output if you're not in a "weird" state) is specific to @. For me, it doesn't seem like a strong argument to say that it shouldn't have a -r flag because some small (almost esoteric) aspect of its output is revision-independent.

One of the main reasons I like jj's CLI more than git's is that I don't need to learn a bunch of different commands and syntaxes for doing the same thing. git forces me to use different commands or different weird syntax for showing changes to the working copy versus other changes, or for restoring one file versus all files, or for comparing a change to the current working copy state versus comparing it to some other state. Any command that does revision-specific things (as jj status does) and hardcodes a revision (especially @) is a "bad old days of git" command for me, as is an answer of "run this other command instead of passing -r".