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

## 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:

```console
$ 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:

```console
$ 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:

```go
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//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 ` (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.