feat: structured logging + opt-in debug mode (Phase 7)

[kurok]

Closes #13. Part of plan #15.

Motivation

Phase 4's dogfood failures (#18, #19) took three iterations and a full revert to diagnose because the ephemeral EC2 instance is terminated by the stop-runner step before anyone can look at cloud-init logs. Structured action-side logs are the cheap half of the diagnostic story (see #20 for the AWS-side exec > … | tee | aws s3 cp … trap that completes it).

What lands

• New src/log.js — JSON-shaped events via core.info / core.warning / core.error. Lazy-requires ./config so validation-phase log calls don't crash before Config is constructed. Auto-redacts values under a small secret-key allowlist (githubToken, token, aws-access-key-id, …).
• New debug input (default false). When set to true, the action emits extra diagnostic traffic — full DescribeImages response, per-poll wait_for_runner details, sanitized input echo. No change to default output.
• Call sites instrumented across src/aws.js / src/gh.js / src/index.js: run_instance, describe_images, wait_for_instance, associate_address, terminate_instance, gh_registration_token, remove_runner, wait_for_runner.
• core.startGroup / endGroup around start() and stop() so the Actions run log collapses.
• Tests: 7 new in tests/log.test.js, 2 new in tests/config.test.js. Total 23 → 30.

Example output

With debug: false (default) — one JSON line per notable event:

::notice::{"step":"describe_images","mode":"start","owner":"699717368611","filters":[...]}
::notice::{"step":"describe_images","mode":"start","match_count":6,"selected_ami":"ami-06150d38a88f1778a"}
::notice::{"step":"run_instance","mode":"start","ami_id":"ami-06150d38a88f1778a","instance_type":"t3.medium","subnet_id":"subnet-01c4ff5a","sg_id":"sg-106ec76d","iam_role":"AmazonSSMRoleForInstancesQuickSetup","label":"abcde"}
::notice::{"step":"run_instance","mode":"start","instance_id":"i-02317df7bd1d30105","elapsed_ms":3140}

With debug: true — adds:

::notice::{"step":"start_inputs","mode":"start","debug":true,"githubToken":"***","label":"","ec2InstanceType":"t3.medium",...}
::notice::{"step":"describe_images_all","mode":"start","debug":true,"images":[{"id":"ami-...","name":"nc-al2023-...","created":"..."}]}
::notice::{"step":"wait_for_runner_poll","mode":"start","debug":true,"label":"abcde","elapsed_s":30,"found":false,"status":null}

Secrets never appear in logs. The sanitize-then-stringify pass in emit() runs on every field payload, including recursively through nested objects.

Compatibility

• Default behavior unchanged for consumers — debug defaults to false → no additional log traffic.
• External contract (inputs + outputs) unchanged: all pre-existing inputs + the two outputs (label, ec2-instance-id) work exactly as before.
• No change to the EC2 bootstrap / user-data — this entire PR operates on the action's JS side, running on the GitHub runner that calls the action.

Unblocks

• Phase 4.b: drop runner to non-root user — second attempt with bootstrap debuggability #20 (Phase 4.b, non-root retry): now has visibility into what the action is doing. Paired with the S3-upload trap on the AWS side (also scoped in Phase 4.b: drop runner to non-root user — second attempt with bootstrap debuggability #20), bootstrap regressions become diagnosable from outside the instance.
• Future retry logic (Phase 5, Phase 5: lifecycle & cleanup reliability — retries, timeouts, always-cleanup #11): built-in hook for log.info('retry', {attempt, delay_ms, reason}) without more boilerplate.

Dogfood

Behavior change is log-output-only — nothing in this PR affects how the EC2 instance boots or how the runner registers. Rotating the provider's pin to this tip should be risk-free; if the pin rotation's CI passes it validates the full action pipeline under the new logging.