WP: declarative multi-project provisioning via lerdstead.yml

[millancore]

Registering projects one by one with lerd link works fine until you set up a new machine or juggle a dozen client projects, at which point a single file describing everything the machine serves is the workflow people coming from Homestead expect. This adds that: a lerdstead.yml file listing sites, services, and parked directories, and a lerd apply command that converges the machine on it.

The file lives at ~/.config/lerd/lerdstead.yml by default, and lerd apply also takes an explicit path so it can live in a dotfiles repo. Each site entry declares a path plus optional domains, php_version, secured, and services. Applying is idempotent: a path lerd does not know yet goes through the normal link pipeline, so the project's committed .lerd.yaml, framework detection, and required services all apply exactly as they would for a manual lerd link, while an already registered site is updated in place through the same funnels the CLI already uses for domain, PHP, and HTTPS changes. A top-level services list keeps global presets installed and running, with name@version pinning, and a park list feeds the existing parked-directories mechanism.

Pruning follows Homestead semantics with a safety rail. Sites provisioned from the file carry a lerdstead marker in sites.yaml, and only marked sites are eligible: remove one from the file and the next apply offers to unlink it, with a yes flag to skip the prompt and a report-only mode for non-interactive runs. A manually linked site is never touched. A few deliberate choices along the same line: an absent secured key leaves the site's current HTTPS state alone instead of forcing it off, a declared domain that already belongs to another site is skipped with a warning rather than stolen, and nothing from lerdstead.yml is ever written into a project's committed .lerd.yaml, since the two files answer different questions, project shape versus which machine serves it.