feat: read INITIAL_PASSWORD env var during setup

[linhdmn]

Summary

Allow users to set the admin password via the INITIAL_PASSWORD environment variable during omniroute setup.

Problem

The resolvePassword() function in bin/cli/commands/setup.mjs only reads the password from the --password CLI flag or interactive prompt. The INITIAL_PASSWORD env var (loaded via loadEnvFile() in omniroute.mjs) is completely ignored.

Fix

Add a one-line check for process.env.INITIAL_PASSWORD in resolvePassword(). The new resolution priority is:

1. --password CLI flag (highest)
2. INITIAL_PASSWORD env var
3. Interactive prompt
4. Skip / no password

Change

bin/cli/commands/setup.mjs — +1 line

[diegosouzapw]

Thanks for this — nice catch, and a clean minimal fix. I confirmed with a local test that omniroute setup --non-interactive currently leaves the dashboard login disabled (requireLogin: false, no password stored) even when INITIAL_PASSWORD is set, until the actual server boots once (there's a separate runtime bootstrap in src/lib/auth/managementPassword.ts that self-heals this on server startup, but your fix closes the gap for CLI-only/scripted setups where the server hasn't started yet). Your one-line change correctly routes through the existing setupPassword()/hashManagementPassword() flow, so the 8-character minimum and hashing still apply — good.

The one thing we need before this can merge is test coverage: the existing tests/unit/cli-setup-command.test.ts doesn't exercise the INITIAL_PASSWORD path yet, and our contribution guidelines require a regression test for any production code change. Could you add:

1. A test that --non-interactive (and the interactive "no --password" case) picks up INITIAL_PASSWORD and results in requireLogin: true with a correctly-hashed password.
2. A test that an explicit --password flag still wins over INITIAL_PASSWORD (the priority order you described in the PR body).

Happy to help if you'd like guidance on the test setup (see the withTempEnv helper already in that test file). Once tests are in, this should be good to merge.

[diegosouzapw]

Thanks @linhdmn — merged into release/v3.8.49 via the local merge-train (validated as one combined tree: full test:unit + test:vitest 274/274 on the 32-core box, tip d4b9ce6016). Your commit keeps its authorship. 🚀