Add coop up --new-instance for a second instance on one project

[DarkaMaul]

coop up treats the project directory (or --git-repo URL) as the instance
identity: it reuses the instance already recorded for that path and applies
creation-only inputs only when it creates one. There was no way to ask for a
second environment on the same source tree — the existing instance always won.

--new-instance skips the workspace/git-repo lookup and creates a separate
instance instead. It requires --name, since the project-derived name is
already taken by the first instance.

coop up ./my-project                                  # first instance
coop up ./my-project --new-instance --name worker-2   # sibling instance

Behavior notes

• Re-running the same --new-instance --name X fails in allocate_instance
  with Instance 'X' already exists, so the flag is not idempotent the way
  plain up is.
• After the sibling exists the directory has two matching instances, so plain
  coop up DIR reports the existing "Multiple instances share workspace"
  ambiguity error instead of picking one, including when --name is given
  (up bails during the lookup, before the name is considered). Instances are
  addressed by name from then on: coop start <name>, coop shell <name>.
  Whether up --name should instead select the named sibling is a separate
  decision — flagging it here rather than changing up's semantics in this PR.

Tests / gates

• New unit tests cover the clap contract: --new-instance parses with
  --name, and errors with MissingRequiredArgument without it.
• cargo fmt -- --check, cargo clippy --all-targets --all-features -D warnings, cargo test (1113 passed) — all green.
• Not run: the integration suite on either backend. The flag's runtime effect
  (bypassing the lookup and booting a sibling VM) has no tests/integration.sh
  phase; cmd_up/cmd_up_git_repo are excluded from the mutation sweep by the
  existing \bcmd_[a-z_]+\b rule, so the guard has no unit-level coverage
  either. An integration phase next to the existing two-instance phase is the
  gap to close before merge.

[hbrodin]

Reviewed base 229c2d106e68 through head 8c1a75964afd. One finding: missing runtime coverage for sibling creation. Correctness, design, conventions, security, API usage, tests, docs, and comments lenses were covered; none skipped. No substantive diff-noise concerns or prior unresolved feedback.

Validation included diff checks, call-chain and CI inspection, and a standalone probe using pinned clap 4.6.6 that confirmed the name requirement and demonstrated that removing it defeats the rejection assertion. Full project tests and Lima/Firecracker integration were not run locally. CI is green but includes neither VM integration gate.

[hbrodin]

Please add runtime coverage for sibling creation. Neither this lookup bypass nor the Git URL bypass is exercised by tests: the new tests only parse arguments, and the existing multi-instance integration phase uses different directories. Both handlers are excluded from mutation testing, so removing either bypass would leave those checks green.

Add integration coverage for directory and Git URL siblings that verifies independent instances, duplicate-name rejection, and subsequent plain-up ambiguity, and run it on Lima and Firecracker before merge.