fix(boot,make): the HTTPS banner lied, and HTTPS_HOST could silently no-op (#128)

[JC-000]

Closes #128.

"Wikipedia build still connects to foo.bar" turned out to have two independent causes, and neither is a bad hostname. The connection was correct throughout — http_host_target drives both the SNI copy and net_dns_resolve, and always did.

1. The banner was a hardcoded literal

do_https_get printed "HTTPS GET WWW.FOO.BAR..." unconditionally. So a make HTTPS_HOST=en.wikipedia.org build announced foo.bar on screen while fetching wikipedia perfectly well — and the only thing an operator can see said the knob had done nothing.

It now prints the real host, assembled at runtime from http_host_target and fed through ascii_chrout (the host is ASCII, and raw ASCII lowercase renders as PETSCII graphics in the default charset — issue #28 — which would turn en.wikipedia.org into line noise).

2. make HTTPS_HOST=<other> could do nothing and exit 0

macOS ships GNU Make 3.81, which compares mtimes at 1-second resolution. A boot.o rebuilt in the same second as the previous link is not "newer" than the PRG, so the link is skipped. Measured: make then make HTTPS_HOST=en.wikipedia.org back-to-back printed nothing, exited 0, and left a PRG still carrying the old host.

This flag is documented as not needing make clean, so it has to be right without one. Three shapes, all measured:

approach	result
delete boot.o only (the old rule)	link skipped, stale PRG — the bug
delete boot.o + PRG inside the recipe	worse: make stats targets before that recipe runs and caches the result, so it skipped the link anyway and left no PRG at all, still exit 0
compare-and-invalidate at Makefile parse time	works — runs before make builds its file database. Absence is not a timestamp comparison.

The Makefile's own comment already recorded the same-second relink as a known, accepted caveat ("check the PRG hash when a build matters") and noted that deleting $(PRG) in the recipe does not fix it. That prose is now retired for this flag. It still stands for BACKEND= and the others, which have no equivalent hook — make clean remains the remedy there.

Also in this change

• $(PRG)'s recipe removes its target before linking. ld65 writes nothing when a memory area overflows, so a failed link left the previous image on disk — and every rig loads build/c64-https.prg by path (rig_https_wiki.py:135). The operator then runs a stale image and reports "the knob did nothing" instead of "the build failed". .DELETE_ON_ERROR does not cover this and was tried first: it deletes a target only if the recipe changed it, and here the file is never touched. It's kept for the partial-write case it does cover, with an honest comment about what it doesn't.
• That explanation lives above the rule, not in the recipe body: make echoes recipe comment lines into every build's stdout, and prose containing the word "overflows" is exactly what scripts grep build output for. The first draft produced a five-profile false FAIL in my own harness.

Verification

• Same-second host switch, no make clean: 3/3 runs produce a PRG carrying en.wikipedia.org with no foo.bar left in it. Switching back is clean, and an unchanged-flags make still runs zero compile/link commands.
• All five profiles build the reporter's command with the real host byte-checked in the image, not merely linked.
• A deliberately overflowing link now leaves no PRG at all.
• tools/test_http.py in VICE: 66/66 uci, 61/61 ip65. tools/test_tls_handshake.py: 21/21. Bare pytest: 31 passed.

Not covered: no hardware run. The on-screen banner is verified by byte inspection of the image and by the primitives it reuses (print_string + ascii_chrout, the issue #28 path), not by reading a real C64 screen.

🤖 Generated with Claude Code