feat(instances): import local standalone nullclaw homes

[vernonstinebaker]

Summary

• add support for importing local same-machine NullClaw standalone homes from either the default ~/.nullclaw path or a custom path
• add standalone detection and imported-runtime handling so attached custom-path installs report correctly in NullHub
• add the install-page UI flow for attaching an existing NullClaw with path and optional name

Testing

• zig build test --summary all
• zig build
• npm run build

Notes

• scope is limited to local same-machine NullClaw imports
• imported external instances are expected to follow the normal log convention: logs/stdout.log 2>&1
• no automated UI test harness was added in this change

[Luckz]

On my Windows OS this doesn't work (creates empty folder when trying to import, then cannot proceed in any way).

[vernonstinebaker]

Sorry for the slow reply — I dug into what could produce an empty folder plus a dead end on Windows, and it's a real bug in the import flow, not something you did wrong.

The import attaches your existing NullClaw home (e.g. C:\Users\you\.nullclaw) into NullHub's instances folder using a filesystem symlink. Windows only permits symlink creation with admin rights or Developer Mode enabled — without that, the request fails partway: the parent instances folder is already created (the empty folder you saw), the symlink is denied, and the hub returns a generic 500 with no useful message. Retrying fails the same way, hence "cannot proceed in any way."

Two things would confirm it:

1. Do you have an existing install at C:\Users\<you>\.nullclaw\config.json? (Import attaches an existing local NullClaw — it doesn't create one.)
2. Is Developer Mode off? (Settings → Privacy & security → For developers)

Immediate workaround: enable Developer Mode (or run the hub once from an elevated terminal) and retry — it should get past the symlink step.

Could you run the above and confirm whether it addresses the problem? If it does, please open a new ISSUE describing the original failure (with your Windows version) and we'll address the underlying symlink behavior in a new PR.