Prototype Azure provider-native setup readiness

[rishabkumar7]

Summary

Prototype replacing the Azure release-mode SSH marker readiness wait with Azure VM Custom Script Extension provisioning status.

Background

Issue #90 documented provider-native setup readiness options. Azure is the best first candidate because azurerm_virtual_machine_extension can expose setup success/failure through Terraform without adding learner-facing IAM or SSM-style dependencies.

Prototype scope

• Azure only.
• Release mode only.
• Preserve use_local_setup=true contributor behavior and the existing local upload/test path.
• Keep existing setup marker files for troubleshooting consistency.
• Keep learner deployment simple: no extra manual Azure setup beyond the existing Terraform inputs.

Acceptance criteria

• Evaluate whether azurerm_virtual_machine_extension can run the release setup flow and make Terraform wait for extension success/failure.
• Document any VM agent, logging, timeout, script size, or troubleshooting differences.
• Ensure public_ip_address is not exposed as ready until setup completes in release mode.
• Confirm contributor-mode testing behavior remains unchanged.
• Decide whether the Azure prototype is cleaner and reliable enough to replace the current Azure SSH marker wait.

Related to #90.

[github-actions]

Thanks for reporting this issue! 👋

Before we proceed, please check our FAQ page.

If your issue isn't addressed in the FAQ, please provide:

• Steps to reproduce
• Expected behavior
• Actual behavior
• Any relevant error messages
• Screenshots, if applicable

This will help us investigate and resolve your issue more quickly.

[rishabkumar7]

Posted findings from validating and fixing the post-reboot test path:

• The original reboot verification flow was not reliable across a real VM restart because the test harness stored its reboot marker and progress snapshot under /tmp, which does not survive reboot consistently.
• The orchestration flow also needed to re-copy the VM test script after reboot and chmod +x it before re-running it.
• While validating the fix, I found two more harness bugs:
  • _reboot_vm was mixing log output into stdout, which polluted the captured IP value used after reboot.
  • reboot/post-reboot failures could be masked and still produce a passing overall result.

Fixes applied:

• test_ctf_challenges.sh
  • moved reboot-state files from /tmp to a persistent per-user directory under $HOME
  • added an explicit --post-reboot mode for the second-phase verification
• deploy_and_test.sh
  • now re-copies the test script after reboot
  • now chmod +x before invoking the post-reboot phase
  • keeps _reboot_vm stdout clean so the returned IP is usable
  • correctly fails the run if reboot, SSH recovery, or post-reboot verification fails

Validation result:

• Re-ran the full Azure contributor-mode test with reboot: ./.github/skills/ctf-testing/deploy_and_test.sh azure --with-reboot
• Final result: RESULT: PASS (azure)
• The post-reboot block ran successfully and verified:
  • ctf-secret-service
  • ctf-monitor-directory
  • ctf-ping-message
  • ctf-secret-process
  • nginx
  • progress persistence (19 checks)