test: reproduce init hang with pinned engine 1.13.50

[nachoaldamav]

Purpose

Reproduce the init@v3 hang some users hit after Setup complete. Open a new terminal to start using Bit. (reported for workspaces pinning an older Bit engine).

What changed

• test-data/workspace.jsonc: pin teambit.harmony/bit.engine to 1.13.50 (previously no engine pin → installed latest bit 2.0.26, which only warns about the new Node ≥ 22.22 requirement instead of hanging).
• .github/workflows/main.yml: add timeout-minutes: 15 on the Initialize Bit step so a reproduced hang aborts fast instead of hitting the 6h job limit.

Hypothesis under test

The action pins node-version: '22.14' (action.yml), but current Bit requires Node ≥ 22.22.0. Latest bit tolerates the mismatch as a warning; the older pinned engine (1.13.50) hangs at the setup boundary.

This is a diagnostic branch, not for merge as-is. If the hang reproduces, the follow-up fix is bumping the action's Node pin.

[nachoaldamav]

Closing — this was a diagnostic branch, not for merge.

Result: pinning engine 1.13.50 did NOT reproduce the hang. On a clean ubuntu-latest runner it installed and passed in ~1 min (run 30743385849). So the bit version is not the cause.

Actual root cause: bvm install (without --skip-update-check) makes a post-"Setup complete" network call to check for a newer bvm; on runners with restricted egress it hangs forever. Clean runners have open egress, so they pass.

Fix in #20 (skip bvm update-check + PATH edit, and bump Node 22.14 → 22.22).