feat(apps): add await-processing to poll builds to terminal state

[setoelkahfi]

Adds asc apps await-processing <APP_ID>, which polls
GET /v1/builds?filter[app]={id} until the newest matching build
reaches a terminal state (VALID succeeds; INVALID/FAILED fail) or
times out. Flags: --version, --pre-release-version,
--interval (default 30s), --timeout (default 1800s).

The poll loop and pure classify()/AwaitConfig/AwaitOutcome live in
the shared frontend crate (await_processing.rs) so the behaviour is
testable and reusable; AwaitOutcome serializes without key material.

Co-Authored-By: siGit Code v1.6.7-acp noreply@sigit.si

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[sigit-code-review]

This change introduces a new CLI subcommand asc apps await-processing <APP_ID>, which polls the App Store Connect API for the latest build matching the given app and optional version filters, waiting until the build reaches a terminal processing state (VALID, INVALID, or FAILED) or a timeout occurs. The polling logic, state classification, and result struct (AwaitOutcome) are implemented in a new shared module (await_processing.rs) in the frontend crate, with unit tests for classification and outcome logic. The CLI integration in main.rs wires up argument parsing, configures polling intervals and timeouts, and handles the result, exiting with an error if the build is not valid or if the wait times out. The frontend crate now depends on tokio for async sleep. No previous findings are present, and the implementation is modular and testable as described in the request.

---

Automated review by siGit Code Review · commit 0266d21 · see the review dashboard