fix(lite): load dotenv files before server startup

[tsumon]

Summary

Fixes #3401.

The Lite distribution is built from cmd/server, but the server entrypoint did not load the dotenv file shipped with Lite packages. Starting WeKnora-lite directly therefore ignored .env.lite (and .env) before the container read DB_DRIVER, DB_PATH, JWT_SECRET, and other settings.

This change:

• loads an explicitly configured ENV_FILE when present;
• otherwise loads .env.lite first and .env second;
• preserves the existing process environment over values from files;
• documents the startup behavior for Lite deployments;
• adds regression tests for precedence and explicit file selection.

Testing

• CGO_ENABLED=0 go test ./internal/envfile -count=1
• go vet ./internal/envfile
• git diff --check

The full application test suite was not run locally because this Windows environment has no C compiler for the repository's CGO-bound PostgreSQL parser dependency; the targeted package tests pass.

[tsumon]

Hi @lyingbug, following up on #3618. The latest CodeCC check is green. Please let me know if you would like any adjustments to the dotenv loading change or its tests.

[lyingbug]

#3618 fix(lite): load dotenv files before server startup（@tsumon）

Thanks @tsumon — I agree that directly running the Lite tarball should pick up its configuration without a separate shell source step. I have two concerns with the current loading policy:

1. cmd/server is also the standard backend's entry point, and envfile.Load() runs unconditionally (cmd/server/main.go:43-48). make dev-app already exports .env and .env.local, so their values remain authoritative. However, a standard binary built in the repo root with make build will now automatically read .env.lite too. With no corresponding process variables set, .env.lite takes precedence over .env, including DB_DRIVER=sqlite (internal/envfile/envfile.go:31-38).
2. For Lite, .env supplements .env.lite even when the latter exists. With files copied from the current templates, that imports REDIS_ADDR=redis:6379 and the Langfuse credentials/host. The Redis address selects the Redis/Asynq path despite STREAM_MANAGER_TYPE=memory (internal/container/container.go:438-460,750-771); the Langfuse keys also enable tracing (internal/tracing/langfuse/config.go:79-83).

Could you remove the automatic .env fallback, keep explicit ENV_FILE support and process-environment precedence, and scope automatic .env.lite loading to Lite builds? Looking beside the executable via os.Executable() is reasonable for the tarball, but that path change alone would still affect standard binaries built in the repo root. Please update the docs and regression tests for the chosen policy, including standard startup and Lite startup with both files present, and confirm that it fits the intended packaging flow.

I also noticed that dotenv loading happens after the logger's package initialization, so file-based LOG_LEVEL and LOG_PATH are not applied. Please call logger.ConfigureFromEnv() after loading, as the desktop entry point already does (internal/logger/logger.go:230-258; cmd/desktop/main.go:177-180).

[tsumon]

Thanks for the detailed review! Updated:

• Automatic loading is now scoped to Lite builds via the existing handler.Edition build-time flag — standard binaries load nothing automatically.
• Dropped the .env fallback entirely; .env.lite is the single file source on Lite builds.
• .env.lite is resolved beside the executable first (fits the package-lite.sh tarball layout), then CWD.
• logger.ConfigureFromEnv() is now called after loading, mirroring cmd/desktop.
• Docs and regression tests updated, covering standard startup and Lite startup with both files present.