fix: poll for publish completion in interactive sdk publish

[mrafnadeem-apimatic]

Problem

The two modes of apimatic sdk publish disagreed about when the command was done.

• Interactive returned as soon as the publishing API accepted the POST. It printed "To view the status of publishing, please visit…" and returned success(), so the command exited 0 whether publishing later succeeded or failed.
• Non-interactive polled getSdkPublishingLog every 10 s to a terminal state, printed the closing note, and returned failed() when publishing did not succeed.

On cancellation with Ctrl+C, the CLI should say, Publishing is still running on APIMatic and will continue without the CLI..

Change

Polling moved into the shared SdkPublishAction, so both modes run one identical post-POST sequence: running notice → poll → closing note with the log URL. The poll runs after the withDirPath block closes, releasing the temp directory holding the zipped SDK before the CLI sits waiting for minutes.

• Interactive's sdkPublishingInProgress message is deleted — publishing is no longer in flight when the command exits, so its wording had become wrong. Non-interactive's log URL wording is reused verbatim for both outcomes; the log URL is useful on success and essential on failure.
• pollPublishingStatus returns 'succeeded' | 'failed' | 'cancelled' (exported from the prompts module, following QuickstartFlow). A boolean cannot express cancel-vs-fail, and the distinction matters for planned work. ActionResult stays out of the prompts layer.
• SdkPublishAction.execute now returns Promise<ActionResult> rather than ActionResult<PublishingInfo>. Nothing reads the payload now that the action prints its own notes, and the old signature carried a hazard: the dry-run branch returns success() with no value, so getValue() on it throws.
• Non-interactive behaviour is unchanged.

Deliberately not in scope

• The completion predicate is unchanged. events.every(...) is vacuously true on an empty array, so an empty or partially-populated publish log reports instant false success. Tracked in sdk publish: missing array length check makes an empty publish-log report a false success #312, along with the lack of retry tolerance on transient status-fetch errors and the unbounded wait.
• No timeout. Any ceiling is a guess about the slowest legitimate publish, and guessing low turns a slow success into a reported failure. Ctrl+C is the interactive escape hatch; job timeouts are the CI one.
• The poll loop stays in the prompts layer, moved verbatim. Relocating it to a service (as portal-service.ts's pollUntilCompleted would suggest) means inventing a status-callback seam across a layer boundary — a refactor riding along on a parity fix.
• No telemetry for publishes that fail after being accepted. SdkPublishValidationFailedEvent models a rejected publish request; folding remote failures into it would corrupt that metric. Tracked in sdk publish: no telemetry for publishes that fail after being accepted #313.

Testing

test/ has no publish coverage and no prompts tests at all. Meaningful coverage here needs either fake timers plus stdout capture against a live clack spinner, or dependency injection into SdkPublishAction (which constructs its own SdkPublishPrompts, PublishingApiService, and GenerateAction) — either is larger and riskier than this parity fix. Verified manually instead.

Automated: pnpm build and pnpm lint clean.

Manual (against a real publishing profile):

1. Interactive, Package + Source Code → polls to [Published] | [Published], exit 0.
2. Interactive, package-only → one target in the status line.
3. Interactive, a publish that fails → exit 1, log URL printed.
4. Interactive, Ctrl+C mid-poll → immediate exit, "still running" notice, log URL.
5. Non-interactive regression → output unchanged.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[saeedjamshaid]

Automated review of the polling change. 15 findings: 6 correctness issues in the new pollPublishingStatus loop and the action wiring, 1 architecture note, and 8 quality/hygiene items. Ordered roughly most-severe first in the inline comments below.