feat(compiler): resolve the install root from the binary's location

The engine runtime and the bundled ludic.* packages belong to the toolchain,
not to the project, so the compiler has to know where the toolchain lives. It
derived that from the directory the binary sits in, which is `bin` — so an
in-repo build only found runtime/native/cocoa.ll when the caller set
LUDIC_HOME=., and an installed compiler had no way to find it at all.

ludic_home() derives it properly instead: $LUDIC_HOME when set, else the
binary's directory with a trailing `bin/` stripped, else a $PATH scan for
argv[0] (an install is invoked by bare name, which carries no directory). Both
layouts that exist then have the same shape — ~/.ludic/{bin,runtime,packages}
and a repo checkout — so the same rule serves both and LUDIC_HOME becomes an
override rather than a requirement.

`import "ludic.core/…"` also falls back to $LUDIC_HOME/packages, after the
project's own ludic_modules/, so a project that has not fetched its own copy
gets the packages that shipped with the toolchain instead of a symlink farm.

The `ludic` multi-call name is dropped from the compiler: that name now belongs
to the CLI, and --run is the flag it drives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

selfhost/backend/stdlib/emit_color.ludic

@@ -5,8 +5,8 @@
 # no allocation, identical codegen to writing the hex by hand. Unknown names are
 # a compile error (color_lookup returns -1, which emit_expr reports).
 #
-# GENERATED by `x docs-palette` from the single source-of-truth palette table
-# in tools/x/docgen.ludic. Edit the palette there and regenerate; do not hand-edit.
+# GENERATED by `ludic dev docs-palette` from the single source-of-truth palette table
+# in tools/ludic-cli/docgen.ludic. Edit the palette there and regenerate; do not hand-edit.
 # ============================================================================
 
 function color_lookup(name: pointer) -> int {