[bug]: artifact delete proceeds with delete after interactive project selection fails or is cancelled

## Description
`harbor artifact delete` (no args, interactive mode) swallows the error from `prompt.GetProjectNameFromUser()` — it only logs it — and continues into `GetRepoNameFromUser` / `GetReferenceFromUser`, eventually calling `api.DeleteArtifact` with empty values. Cancelling the project picker (Esc) therefore produces a confusing API error instead of a clean abort.

The sibling commands `artifact label delete` (`cmd/harbor/root/artifact/label/delete.go:61-64`) and `repository delete` (`cmd/harbor/root/repository/delete.go:41-44`) already return the error correctly — `cmd/harbor/root/artifact/delete.go:40-43` is the outlier.

I searched the open/closed issues and PRs around this area — the log-and-continue family (#865/#862), the output cleanup in #953 (and #881), and the open artifact tags panic (#1069/#1071) — and couldn't find this particular path covered. Would appreciate a pointer if I missed it.

## Steps to Reproduce
1. Run command: `harbor artifact delete` (no arguments, interactive mode)
2. With arguments/config: at the project picker, press Esc / Ctrl-C (or run against an instance where project listing fails or returns no projects)
3. Observe error

## Expected Behavior
The command aborts cleanly, e.g. `Error: failed to get project name: user aborted project selection`, exits non-zero, and makes no `DeleteArtifact` API call.

## Actual Behavior
The prompt error is only logged via `log.Errorf`, execution continues with `projectName == ""`, and `api.DeleteArtifact("", "", "")` is called, surfacing a confusing downstream API error instead of the real cause.

## Environment
- OS: macOS / Linux
- Tool version: `main` (verified against `origin/main`, `cmd/harbor/root/artifact/delete.go`)
- Other relevant details: Interactive TUI mode only; arg mode (`harbor artifact delete /:`) is unaffected.

## Additional Context
Proposed scope: return the prompt error in `cmd/harbor/root/artifact/delete.go` (matching the sibling pattern: `fmt.Errorf("failed to get project name: %v", utils.ParseHarborErrorMsg(err))`) plus an empty-value guard before `DeleteArtifact`. No changes to `pkg/prompt` helper signatures.

I’m happy to prepare a PR for this if the team is aligned , however please let me know if there’s another direction you'd prefer to take...! :)

Start with the interactive path in cmd/harbor/root/artifact/delete.go:40-43, then compare the error handling in cmd/harbor/root/artifact/label/delete.go:61-64 and cmd/harbor/root/repository/delete.go:41-44. Verify the project-selection error is returned and that cancellation or failure cannot reach api.DeleteArtifact with empty values; arg mode should remain unaffected.

Written by the indexing model from the issue text.