feat(installer): harden ZCode 2.0.1 setup lifecycle

[rldyourmnd]

What changed

• harden install, update, switch, restore, remove, adoption, and bootstrap as identity-bound transactions with exclusive native renames, fail-closed recovery, and bounded runtime probes
• pin the complete ZCode 3.3.3 artifact matrix and validate macOS signing identity, Debian package identity, embedded CLI payloads, and postconditions
• finalize the portable builder, designer, and developer setup profiles while keeping development validation outside the public module
• move all reusable workflows to nddev-ci-workflows@0.5.0, add actionlint and pedantic zizmor SARIF, and publish an immutable attested four-asset release
• synchronize public contracts, security guidance, and the 2.0.1 changelog

Why

The previous lifecycle relied on weaker filesystem ownership assumptions, permissive option/version handling, incomplete artifact identity checks, and setup metadata that could drift from the actual ZCode runtime. This change makes every destructive transition explicit, recoverable, versioned, and independently validated by the private nddev-harnesses control plane.

Validation

• private harness: 421 passed, 0 failed, 0 skipped
• Python 3.10 native lifecycle lanes: macOS and Ubuntu PASS
• Ruff: clean and formatted; Pyright: 0 errors, 0 warnings
• Bash syntax and ShellCheck: PASS
• actionlint: PASS
• zizmor 1.26.1, pedantic, minimum low: no findings (one documented privileged-trigger exception)
• macOS and Ubuntu lifecycle benchmarks: 8/8 scenarios each, no regressions
• public/private boundary, shared-CI provenance, Markdown, component metadata, JSON, and diff validators: PASS

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.