PR #3333 - hatayama/unity-cli-loop

Summary

With ULOOP_DEBUG set, each uloop compile-check run now writes what it did to the project's CLI VibeLog. The log shows what was compiled, reused, checked on changed files, or blocked, why a run fell back, and how long each assembly took.

Before: compile-check never talks to the Editor, and it wrote nothing to the VibeLogs even with ULOOP_DEBUG set. A long session of runs could not be reconstructed afterwards. Which run took the changed-files check, which fell back and why, and where the time went were all lost once the JSON output scrolled away. Runs that exited 1 were the hardest to recover.
After: every run leaves two lines in .uloop/outputs/VibeLogs/cli_vibe_<UTC date>.json, sharing one correlation_id.

cli_compile_check_start (INFO) is written once the project is found. Its fields are command, all, full, jobs, project_identity.
cli_compile_check_complete is written on every way out of a run that wrote the start entry:
- outcome, with the entry's level:
  - succeeded: INFO.
  - errors: WARNING, when compile errors were found.
  - failed: ERROR, when the Editor could not be resolved, the run itself failed, or the response could not be encoded.
- duration_ms of the whole run.
- For failed: error and error_code.
- Otherwise, the response's own lists and counts: error_count, warning_count, compiled, reused, fast_checked, blocked, skipped_count, fast_checks (assembly, reused, changed_file_count), fallbacks and baseline_notes (assembly, reason).
- units, with the duration_ms and succeeded of each assembly the run compiled or checked. Replayed ones are left out, since they took no work.
Without ULOOP_DEBUG, nothing is written and no context is built.
A failed write is ignored; the log never fails a run.
docs/vibe-logs.md documents both entries, and docs/compile-check.md mentions them.
cli/common is unchanged.

New tests:
- a successful run writes both entries with one correlation id, and every listed field matches the run;
- a run with errors is logged as WARNING with the errors counted;
- a failed run is logged as ERROR with the error and its code;
- runCompileCheck on a project whose Editor is not installed writes a start entry and a failed complete entry of the same run.

Mutations, each restored afterwards:

Mutation	Fails
No `failed` entry when the Editor cannot be resolved	the Editor-resolution test
The complete entry uses another correlation id	all four tests
`outcome` is always `succeeded`	the errors, failed, and Editor-resolution tests
`fallbacks` is always empty	the successful-run test

cli/dispatcher:
- golangci-lint fmt --diff is empty; go vet ./... passes; golangci-lint run and the complexity config both report 0 issues.
- go test ./... and go test -race on the compile-check and dispatcher packages pass.
- Coverage with the CI exclusions: 94.25% (baseline 94.2).
cli/release-automation: go test ./... passes; check-skill-size passes; the file-length check passes.
scripts/sync-tool-docs.sh --check reports no drift.
Repository CI does not run on pull requests into this branch; the checks above were run locally.