[bug]: tag retention delete fails with --project-id

## Description

The `harbor tag retention delete` command supports both `--project-name` and `--project-id`, but the resolved retention policy ID is not correctly passed through the deletion flow.

When the command is invoked using `--project-id`, the CLI successfully resolves the retention policy ID, but `api.DeleteRetention()` is called with `projectName` instead. The API layer then attempts to resolve the retention policy again using the project name, which is incorrect for the `--project-id` path.

## Steps to Reproduce

1. Create a project with a tag retention policy.
2. Note the numeric project ID.
3. Run the retention deletion command using the project ID:

```bash
harbor tag retention delete --project-id
```

4. Select a retention rule when prompted.
5. Observe the deletion behavior.

## Expected Behavior

The command should use the already-resolved retention policy ID to retrieve and update the retention policy.

The deletion should work correctly regardless of whether the project was specified using `--project-name` or `--project-id`.

## Actual Behavior

The CLI resolves the retention policy ID but passes `projectName` to `api.DeleteRetention()`.

The API layer then performs another `GetRetentionId(projectName, true)` lookup instead of using the already-resolved retention ID.

When using `--project-id`, this can result in an incorrect project-name lookup and cause the retention rule deletion to fail.

## Environment

- OS: Windows
- Tool version: Harbor CLI from `main`
- Other relevant details: Reproduced by inspecting and testing the current `origin/main` implementation.

## Additional Context

The current flow is:

```text
--project-id / --project-name
↓
GetRetentionId()
↓
retentionID
↓
DeleteRetention(projectName, ruleIndex)
↓
GetRetentionId(projectName, true)
↓
ListRetention()
```

The resolved `retentionID` should instead be passed directly to the API deletion function:

```text
--project-id / --project-name
↓
GetRetentionId()
↓
retentionID
↓
DeleteRetention(retentionID, ruleIndex)
↓
ListRetention(retentionID)
```

This also avoids performing the retention ID lookup twice.

A previous PR (#996) addressed a different retention-rule deletion issue but was closed with unmerged commits. The current `origin/main` still contains the project-name based lookup shown above.

Start at the retention delete command and trace the calls to GetRetentionId, api.DeleteRetention, and ListRetention. Run the documented --project-id reproduction, then verify that the resolved retention ID is used through deletion and that both --project-id and --project-name paths work without a second lookup.

Written by the indexing model from the issue text.