Fixed docs workflows building the v2 binary from the removed '.vortex/installer' path.

[AlexSkrypnyk]

Summary

The Vortex - Test docs workflow on main failed at the "Build and publish v2 installer" step with Invalid working directory specified, vortex-v2/.vortex/installer does not exist. The 2.x branch renamed .vortex/installer to .vortex/cli, replaced the box.json replacement token vortex-installer-version with vortex-cli-version, and now builds .build/vortex.phar instead of build/installer.phar. Both vortex-test-docs.yml (the failing workflow) and vortex-release.yml build the other major's binary by checking out the 2.x branch, and both still referenced the old .vortex/installer layout, so vortex-release.yml carried the same defect and would have broken the next release. This updates the other-major build leg in both workflows to the current 2.x layout, renames the affected step labels from "installer" to "binary"/"artifact" wording since v2 ships a CLI rather than an installer, and switches the docs job's copy step to a *.phar glob since the v2 artifact now contains vortex.phar instead of installer.phar.

Changes

• .github/workflows/vortex-test-docs.yml: build the other major's binary in .vortex/cli instead of .vortex/installer, sed the vortex-cli-version box.json token instead of vortex-installer-version, copy .build/vortex.phar instead of build/installer.phar, and renamed the step to "Build and publish v${{ env.OTHER_MAJOR }} binary".
• .github/workflows/vortex-release.yml: the same working-directory, box.json token, and PHAR path fixes for the "Build v${{ env.OTHER_MAJOR }} binary" step, plus a *.phar glob in the docs job's "Copy binaries to docs" step so it matches whichever PHAR name each major's artifact actually contains, since the artifact is now vortex.phar for v2 rather than installer.phar.
• Renamed step names on the other-major legs from "installer" to "binary"/"artifact" wording in both files to reflect that v2 ships a CLI, not an installer. Artifact names (vortex-installer-vN) are left unchanged - they are internal identifiers consumed within the same workflow run, and 2.x uses the same names.
• Updated the surrounding comments in both files to describe that each major builds and ships its own thing (installer vs CLI) with its own paths.

Verification

actionlint passes on both changed files. The fixed step is gated on head_branch == 'main', so this PR's own CI cannot exercise it - the failure only reproduces on a main docs run. To compensate, the exact CI sequence (composer install, then sed of the vortex-cli-version token in box.json, then composer build) was run locally against the real 2.x .vortex/cli tree. It produced .build/vortex.phar, and ./.build/vortex.phar --version printed Vortex CLI 2.x-dev, confirming the new path, token, and PHAR name all line up with what 2.x actually ships.

Before / After

BEFORE - other-major build leg (checked out from '2.x')
┌────────────────────────────────────────────────────────────────┐
│ working-directory:  vortex-v2/.vortex/installer                 │
│ box.json token:      "vortex-installer-version"                 │
│ built PHAR:          build/installer.phar                       │
│ artifact copy:        installer-v2/installer.phar                │
├────────────────────────────────────────────────────────────────┤
│ result:  Invalid working directory specified,                   │
│          vortex-v2/.vortex/installer does not exist.            │
└────────────────────────────────────────────────────────────────┘

AFTER - other-major build leg (checked out from '2.x')
┌────────────────────────────────────────────────────────────────┐
│ working-directory:  vortex-v2/.vortex/cli                       │
│ box.json token:      "vortex-cli-version"                       │
│ built PHAR:          .build/vortex.phar                         │
│ artifact copy:        installer-v2/*.phar                        │
├────────────────────────────────────────────────────────────────┤
│ result:  ./.build/vortex.phar --version                         │
│          -> Vortex CLI 2.x-dev                                  │
└────────────────────────────────────────────────────────────────┘

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c9ff4af2-1555-405d-8f4a-071abffeea41

📥 Commits

Reviewing files that changed from the base of the PR and between e94fde1 and f1fd611.

📒 Files selected for processing (2)

• .github/workflows/vortex-release.yml
• .github/workflows/vortex-test-docs.yml

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.55% (204/207)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[AlexSkrypnyk]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.55% (204/207)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.49%. Comparing base (e94fde1) to head (f1fd611).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2861      +/-   ##
==========================================
- Coverage   86.91%   86.49%   -0.43%     
==========================================
  Files         100       93       -7     
  Lines        4830     4671     -159     
  Branches       47        3      -44     
==========================================
- Hits         4198     4040     -158     
+ Misses        632      631       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

📖 Documentation preview for this pull request has been deployed to Netlify:

https://6a69881132973464a3b60bfc--vortex-docs.netlify.app

This preview is rebuilt on every commit and is not the production documentation site.