`jj workspace add --ignore-working-copy` fails after partially creating the workspace (or leaves it empty and stale with `--sparse-patterns full`)

Description

When running jj workspace add against an existing repository (for example, with -R <repo>), passing --ignore-working-copy is a natural way to avoid snapshotting—or requiring an up-to-date working copy in—the existing workspace while still creating and populating the new workspace.

However, if jj workspace add is invoked with --ignore-working-copy:

• Under the default --sparse-patterns copy (or --sparse-patterns empty), jj first creates the destination directory, creates the colocated Git worktree (if colocated), initializes <destination>/.jj, and records an add workspace '<name>' operation with the new workspace checked out on root(), and only then fails with Error: This command must be able to update the working copy. Hint: Don't use --ignore-working-copy. This leaves behind a partially initialized workspace checked out on root() instead of the requested revision.
• Under --sparse-patterns full, jj workspace add --ignore-working-copy exits 0 and creates the initial working-copy commit on the requested revision in the repository view, but skips writing the working-copy files to <destination>, leaving the new workspace directory empty on disk and immediately stale (Error: The working copy is stale).
• Similarly, if --at-op or --no-integrate-operation is passed to jj workspace add, it creates the destination directory, Git worktree, and <destination>/.jj before failing (or leaving the workspace in an inconsistent state).

I ran into this in a real-world scenario when trying to create a new secondary workspace from a primary repository whose own working copy had become stale (because an ancestor commit of the primary workspace's @ had been rewritten from another workspace).

Steps to Reproduce the Problem

tmp=$(mktemp -d /tmp/jj-workspace-add-repro.XXXXXX)
jj git init --colocate "$tmp/repo"
cd "$tmp/repo"
echo "hello" > file.txt
jj commit -m "initial"

# Case 1: default --sparse-patterns copy
jj workspace add --ignore-working-copy -r @- "$tmp/ws1"
jj workspace list --ignore-working-copy
jj status -R "$tmp/ws1"

# Case 2: --sparse-patterns full
jj workspace add --sparse-patterns full --ignore-working-copy -r @- "$tmp/ws2"
ls -la "$tmp/ws2"
jj status -R "$tmp/ws2"

Expected Behavior

Either:

1. --ignore-working-copy applies only to the existing (source) workspace—skipping snapshotting and staleness checks on the existing workspace—while the newly created workspace at <destination> is still initialized and populated normally on top of -r @- (with file.txt checked out and an up-to-date working copy); or
2. If jj workspace add is intentionally disallowed with --ignore-working-copy (as well as --at-op and --no-integrate-operation), it rejects the flag upfront before creating <destination>, creating a Git worktree, initializing <destination>/.jj, or committing an add workspace operation.

Actual Behavior

Case 1 (jj workspace add --ignore-working-copy -r @- "$tmp/ws1") fails with exit code 1 after already creating the Git worktree, initializing $tmp/ws1/.jj, and registering ws1 on root() (000000000000) instead of @-:

Created Git worktree for the new workspace.
Created workspace in "../ws1"
Error: This command must be able to update the working copy.
Hint: Don't use --ignore-working-copy.

jj workspace list --ignore-working-copy and jj status -R "$tmp/ws1" then show:

default: . uqurxnlz 5fd9457f6907 (empty) (no description set)
ws1: ../ws1 nvvwuwpx b6f85fb73316 (empty) (no description set)

The working copy has no changes.
Working copy  (@) : nvvwuwpx b6f85fb73316 (empty) (no description set)
Parent commit (@-): zzzzzzzz 000000000000 (empty) (no description set)

Case 2 (jj workspace add --sparse-patterns full --ignore-working-copy -r @- "$tmp/ws2") exits 0, but does not check out file.txt into $tmp/ws2 and leaves ws2 immediately stale:

Created Git worktree for the new workspace.
Created workspace in "../ws2"

jj status -R "$tmp/ws2" then fails with:

Error: The working copy is stale (not updated since operation 3b117e150af1).
Hint: Run `jj workspace update-stale` to update it.
See https://docs.jj-vcs.dev/latest/working-copy/#stale-working-copy for more information.

Specifications

• Platform: Linux (x86_64)
• Version: jj 0.45.1-4df526513289fdee58eb7e8351c2ff87aac099ff (also verified on main at 531b682046880c47ac06a7106c5852e56c046d71)