fix(build): move all back to the first target in Makefile

[agicy]

Summary

Fixes #403.

Restores all as the default goal so a bare make builds hvisor again, and pins it in a way that target order can no longer change.

• Move the all target back to the first position (directly under .PHONY) and add a one-line comment on why it must stay there. The recipe is moved verbatim; the comment and one blank line are the only new lines.
• Set .DEFAULT_GOAL explicitly in the existing ptest block: all by default, ptest when make ptest=<name> is given.
• Remove the clean_check target and its .PHONY entry. It has been dead code since the same commit that caused this regression: all now depends on ensure_config directly, and nothing else referenced the wrapper.

Motivation

PR #319 added kconfig_venv: / ensure_config: above all:, which silently changed the default goal from all to kconfig_venv. A bare make therefore stopped building hvisor and exited 0, breaking the commands documented in hvisor-book (make BID=aarch64/phytium-pi LOG=info, make ARCH=x86_64 BOARD=nuc14mnk, make BID=aarch64/rk3588). Fixing the target order alone would leave the same trap for the next target added above all, so the default goal is now declared explicitly instead of being an implicit side effect of file layout.

The ptest block is written as a single exhaustive decision rather than relying on assignment order: a .DEFAULT_GOAL := all placed after that block silently overrides make ptest=..., which would be the same bug in a new place. Note that any non-empty ptest value selects that goal, so invalid names still fail in ptest-check as before.

Verification (updated)

End-to-end build at the branch head (86f41fd) — a bare make, exactly the command from the issue:

$ make BID=aarch64/sysoul_x3300
No .config; running defconfig for aarch64/sysoul_x3300
Creating tools/kconfig/.venv (kconfiglib)...
wrote .config for aarch64/sysoul_x3300
generating .cargo/config.toml success!
   Compiling hvisor v0.6.0 (...)
    Finished `release` profile [optimized] target(s) in 27.89s
OK: hvisor [0x500000, 0x4a70000) does not overlap any ROOT_ZONE_MEMORY_REGIONS RAM region
hvisor build success!          # exit 0; hvisor.bin 217K, hvisor.elf 460K

Before this fix the same command stopped after the venv bootstrap.

Missing (not run): QEMU boot / functional regression. This change only affects which target a bare make selects; no compilation input, flag, or source file changes.

Risks and Limitations

• Only target selection changes; build inputs and flags are untouched.
• Removing clean_check drops a (dead) user-visible target: invoking make clean_check now reports "No rule to make target". Nothing in the repo, CI, or documentation calls it, and its only action (ensure_config) is still a direct prerequisite of all.
• hvisor-book's affected examples become correct again with this fix; no documentation change is needed.

[agicy]

@dallasxy. Related finding from the same commit, left out here to keep this PR focused on the default goal:

1e0b413 also deleted the fmt-test target from Makefile, but .github/workflows/ci.yml:37 still calls make fmt-test and the same commit commented out that workflow's push/pull_request triggers, so the job now runs only on manual dispatch and would fail with "No rule to make target 'fmt-test'".

Nothing here is blocked by it (GitHub Actions runs no CI checks on this PR; the equivalent check is Jenkins' linter stage, Jenkinsfile:226, and it passes). origin/main still has the target at Makefile:166, so the options are: drop the stale step, restore the target, or re-enable the workflow. Happy to send a follow-up PR for whichever is preferred.