- detect OpenCode v2 (serve --help has --service) and configure it with 'opencode service set hostname/port/password/cors'; the unit runs 'opencode serve --service' (what the v2 manager spawns)
- v2 stores the password in OpenCode's own service config; v1 keeps the EnvironmentFile + flags
- password-based (portable) access for the web app: Add server -> address + password, username 'opencode'
- README documents v2 vs v1
- --cors ORIGIN (repeatable) and an interactive CORS prompt; adds --cors to ExecStart
- warn when a password is set with a username other than 'opencode' (the web UI always authenticates as opencode)
- README: --cors + the 'don't stack two basic-auth layers' note
- the OpenCode web app's 'Add server' dialog asks for server address + password; the username defaults to 'opencode' and is never sent by the browser
- so the installer no longer asks for a username (a custom one would break the web login); --username/OPENCODE_SERVER_USERNAME remain for API clients
- README explains the add-server dialog and what to enter
- install-service.sh: interactive password prompt (hidden input); --password/--username/--no-password and OPENCODE_SERVER_PASSWORD/USERNAME env
- credentials are written to a root-only env file (mode 600) referenced by the unit via EnvironmentFile=; the password never appears in the unit
- unit name/env path overridable for testing (OPENCODE_SERVICE_NAME, OPENCODE_ENV_FILE)
- README documents the auth option
- new install-service.sh: creates/removes the OpenCode web UI systemd service as its own process (interactive by default, flags for automation, --uninstall, --dry-run, backs up an existing unit)
- install.sh no longer embeds the service logic; run_service_setup locates the sibling script (or downloads it) and invokes it as a separate process
- README documents running install-service.sh on its own
