Create SDK applications and prepare DimOS contributor checkouts

[TomCC7]

Create an SDK application or prepare a DimOS contributor checkout with the same bootstrap CLI and activation workflow.

dimup init <directory> [--ref] pins the SDK and its dependency-source policy, installs desktop extras except DDS with uv-managed Python, and generates an editable two-module image example and test. Applications can be edited, committed, cloned, and reproduced from their lockfile.

dimup dev <directory> [--ref] clones upstream with Git history, skips automatic LFS downloads, and installs the checkout editable with runtime/test/lint dependencies and commit hooks. It accepts branches, tags, and commits; defaults to main; and requires a new or empty directory. Native components build on demand. Web builds, existing-checkout setup, and fork creation are excluded.

Both commands show stages and live uv output, retain logs on failure, and print manual activation and optional direnv instructions. Doctor checks either the application SDK pin/registration or the contributor's editable source, along with environment, tools, and runtime libraries. Neither command has a host-platform gate. Machine setup and persistent shell LFS configuration belong to #4042.

The installation test guide uses working PR-branch commands before merge. The contributor flow is also linked from CONTRIBUTING.md and the platform guides.

Validation: 87 focused tests, strict installer/doctor typing, and commit hooks pass. A real local clone installed 470 packages from the lockfile, installed both commit hooks, passed doctor and four repository tests, and reflected a source edit from outside the checkout. Git status was clean after restoring the test edit. The LFS fixture proves cloning leaves pointers and explicit pulls retrieve content. Platform CI now includes the contributor journey alongside application and native replay acceptance on Ubuntu 22.04/24.04 and macOS 14; CI is queued on 2aa46e6.

Frontend tooling is optional: init, dev, and doctor do not require Deno. Platform acceptance now makes any Deno invocation fail, so preinstalled tools cannot hide a dependency. The guides explicitly use the PR branch until the packaging fix reaches main.

Review order: #4042 → #4044 → #4047. Stack: https://github.com/dimensionalOS/dimos/stack/4064

PRD: https://linear.app/dimensional/project/dimos-developer-onboarding-v1-3df889ba9a65

[codecov]

❌ 1 Tests Failed:

Tests completed	Failed	Passed	Skipped
5110	1	5109	186

View the top 1 failed test(s) by shortest run time

dimos.codebase_checks.test_docs_branding::test_docs_use_current_branding

Stack Traces | 0.015s run time

def test_docs_use_current_branding() -> None:
        """Fail if any file under docs/ spells the brand "DimOS" instead of "dimOS"."""
        hits = find_old_branding()
        if hits:
            listing = "\n".join(
                f"  - {p.relative_to(DIMOS_PROJECT_ROOT)}:{lineno}: {line.strip()}"
                for p, lineno, line in hits
            )
>           raise AssertionError(f'Found "DimOS" in docs/:\n{listing}\n\nThe brand is spelled "dimOS".')
E           AssertionError: Found "DimOS" in docs/:
E             - docs/installation/installer.md:136: Doctor should report `PASS  Editable DimOS checkout` along with passing environment,
E           
E           The brand is spelled "dimOS".

hits       = [(PosixPath('.../docs/installation/installer.md'), 136, 'Doctor should report `PASS  Editable DimOS checkout` along with passing environment,')]
listing    = '  - docs/installation/installer.md:136: Doctor should report `PASS  Editable DimOS checkout` along with passing environment,'

dimos/codebase_checks/test_docs_branding.py:43: AssertionError

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[TomCC7]

no adr pls

[TomCC7]

why we need this file?