keep the dynamism of make in pure shell

Two mechanisms, matching what the make engine actually did:

Lazy defaults. A stack setting is a function myos_default_<VAR>, called only
when the variable has no value, and called again at every reference. That is
exactly a recursive ?=: an explicit value wins, and the default follows a
DOMAIN that a .env changes later. The prefix is what makes it safe; the first
version used a bare function named after the variable, and the test suite
caught it running /usr/bin/host for a stack group called host.

Templates. myos env-update fills a .env from the .env.dist files, expanding
${VAR} against the current values and running $(command), forward references
included.

Also fixed: the project .env now wins over /etc/conf.d/myos, which is what the
documentation claimed and the code did not.

share/make/shim.mk lets a project keep make as a front end: every myos command
becomes a target that shells out to bin/myos, and the project keeps its own
targets and its stack .mk files. It sits outside make/ because the legacy
engine globs every .mk in there.

README.md

@@ -124,6 +124,19 @@ The make targets keep working: `print-VAR`, `stack-<stack>-<command>`,
 
 `SETUP_UFW=true` enables the ufw/ufw-docker integration (`myos setup-ufw`).
 
+## With make
+
+A project that would rather drive make can include the shim, which turns every
+myos command into a make target while leaving its own targets alone:
+
+```make
+MYOS ?= /usr/local/lib/myos
+include $(MYOS)/share/make/shim.mk
+```
+
+`make up STACK=host` then runs exactly what `myos up host` runs: the shim only
+forwards. make is not needed otherwise, and the CLI never calls it.
+
 ## For agents
 
 `skills/myos/SKILL.md` is a skill describing how to drive myos, with