v0.4.18

Added

• A "Re-add" tab on the Containers page for workspace containers this host still has but the dashboard is not running. Two things land there: a workspace DevGrail still knows about whose container is bound to a Docker network that no longer exists, and a workspace container the database no longer describes at all. Nothing is re-added on its own — each one comes back only when you say so, and the tab tells you what re-adding will restore before you do. Re-adding a detached workspace rebinds it and starts it with its files, volume, ports and credentials untouched. Re-adding a container DevGrail has no record of rebuilds one from the container itself; the description, documentation, project, app subdomains and API-key grants lived only in the database and do not come back, and its SSH password is reset. The tab is always there, so it can answer "is anything missing?" rather than only appearing once something is. Administrators only, since re-adding decides who owns a workspace.
• uninstall.sh --keep-workspaces removes DevGrail without removing your work. Everything of DevGrail's own goes — the stack, the database, the certificates, the images and the config in /opt/devgrail and /etc/devgrail — while the workspace containers, their volumes, their networks and the image they run on stay where they are. It is the way to start an install over from scratch without losing the workspaces: re-run install.sh and the Re-add tab offers them back with their files, volume and ports intact. What only ever lived in the database — names, descriptions, documentation, projects, app subdomains and API-key grants — comes back by restoring the backup the uninstall takes first, not by re-adding. An uninstall run without the flag now offers the same mode as a question when you decline the full wipe, and the report says up front what keeping the containers does and does not preserve.
• Workspaces in this state now say so. A workspace whose network binding is broken is shown as "detached" instead of appearing to be an ordinary stopped one, and starting it explains what to do rather than reporting a Docker error that names a hexadecimal id and nothing else.

Fixed

• Uninstalling with your workspaces kept no longer leaves them unable to start. A preserved workspace is bound to its Docker network by id, not by name, so removing that network — which the uninstaller did even when it was keeping every container — stranded it: reinstalling recreated a network with the same name and a new id, and starting the workspace failed with failed to set up container networking: network <id> not found. The per-workspace networks are now kept whenever the workspaces themselves are, and only --purge (which removes the containers anyway) removes them.