server start has no datasource control: silently creates c123.db in the current working directory

[ambiorix2099]

Summary

conductor server start gives no way to control where the local server's SQLite database lives. The
server inherits Spring's default datasource, which resolves relative to the current working
directory, so it silently creates c123.db (plus -shm / -wal) wherever the command happened to
be run from.

Three consequences:

1. Running from a git repo drops an untracked, potentially large database into it. c123.db is not
   in this repo's .gitignore, so it can be committed.
2. The same "local server" has different state depending on which directory you started it from —
   with no indication anywhere in the CLI's output.
3. There is no flag or env var to override it.

Found while setting up an isolated environment for regression-testing #100 against 3.32.0-rc.23.

Evidence

The server log shows the CWD-relative datasource:

[main] INFO org.flywaydb.core.FlywayExecutor - Database: jdbc:sqlite:c123.db (SQLite 3.45)

Two databases for the same local server, purely because of where it was started:

$ ls -la .../csharp-sdk/c123.db  /tmp/conductor-e2e/c123.db
440569856  /Users/…/Code/orkes/csharp-sdk/c123.db      # 440 MB — 229 agents, 328 task defs
   393216  /tmp/conductor-e2e/c123.db                   # fresh, empty

The 440 MB file was created by an earlier conductor server start run from a different project
directory. Someone using conductor server start from two repos gets two unrelated servers and no
hint that's happening — the CLI reports the same server status either way, because state is tracked
in ~/.conductor-cli/server/server-state.json by pid/port only.

Not ignored here:

$ git check-ignore -v c123.db
# (no output — NOT ignored)
$ grep db .gitignore
conductorosstest.db          # a *different* db name is ignored; c123.db is not

The presence of conductorosstest.db in .gitignore suggests this has been worked around before,
under a name the server no longer uses.

Root cause

cmd/server.go builds a fixed argument list and offers no passthrough:

javaArgs := []string{"-jar", jarPath}
if port != defaultPort {
    javaArgs = append(javaArgs, fmt.Sprintf("--server.port=%d", port))
}
javaArgs = append(javaArgs, aiIntegrationArgs()...)   // --conductor.integrations.ai.enabled, --agentspan.embedded

There is no --spring.datasource.url set and no way for a caller to add one. Spring Boot
command-line args are the highest-precedence property source, so this would be trivial to inject —
the mechanism is already used for the two AI flags.

Impact

• Accidental commit of a multi-hundred-MB database is possible in any repo where the server is
  started.
• Confusing, hard-to-diagnose state divergence: "my workflows disappeared" when the user simply
  cd'd elsewhere before starting the server.
• Test isolation currently depends on remembering to cd to a scratch directory first — an
  undocumented convention rather than a supported option.

Fix options

A. Default the datasource under ~/.conductor-cli/server/ (recommended). e.g.
--spring.datasource.url=jdbc:sqlite:$HOME/.conductor-cli/server/<version>/conductor.db. Makes the
local server's state stable regardless of CWD, matching where the jar and pid/state already live.
Note this changes behaviour for existing users, whose current data sits in per-directory files.

B. Add an explicit flag — conductor server start --data-dir <path> (or --datasource) — mapped
onto --spring.datasource.url. Gives test harnesses a supported isolation mechanism.

C. Generic passthrough — allow extra Spring args, e.g.
conductor server start -- --spring.datasource.url=.... Most flexible, least discoverable.

D. Minimum viable — add c123.db* to .gitignore and document the CWD dependency in the
server start help text. Doesn't fix the design, but stops the committed-database failure mode.

Recommend A + B: stable default, with a flag for harnesses that want isolation. D is worth
doing regardless as it's a one-line safety net.

Test coverage

server has no E2E coverage today. Any future server.bats will need option B (or the scratch-dir
convention) to avoid polluting the repo when CI runs it — so this issue is a soft blocker on testing
the server command properly.