#2468 serve: workflow trigger get/set ignore --config and read/write <repo>/.swamp/serve.yaml, so they disagree with the scheduler

Problem

When serve is started with --config <path>, the scheduler and the workflow.trigger.* requests use different config files.

• The scheduler loads trigger overrides from the merged config, i.e. the --config file (src/cli/commands/serve.ts:3727-3743). It logs Loaded 1 trigger override(s) from serve.yaml.
• workflow.trigger.get/set/remove read and write <repoDir>/.swamp/serve.yaml, the default path, ignoring --config (src/serve/handlers/workflow_handlers.ts:1750 → readServeConfigFile(ctx.repoDir), serve_config.ts:1245-1248).

Measured (20260923.231117.0)

serve runs with --config=/config/serve.yaml, a Kubernetes ConfigMap mount, containing:

triggers:
  mircloud-sweep-cabling-drift:
    inputs: {proofTarget: production, tlsPolicy: insecure, timeoutMs: 15000, db: {...}}

Startup log: Loaded 1 trigger override(s) from serve.yaml and Registered schedule for workflow "mircloud-sweep-cabling-drift": "0 5 * * *". But:

$ swamp workflow trigger get mircloud-sweep-cabling-drift --server ... --json
{"builtIn":{"schedule":"0 5 * * *","inputs":{}},"override":null,"effective":{"schedule":"0 5 * * *","inputs":{}}}

Impact

1. trigger get reports override: null and empty effective inputs for an override that is live. The one tool meant to answer "what will this schedule run with" gives the wrong answer.
2. trigger set would write a second, divergent serve.yaml under the repo dir and apply it live through updateTriggerOverrides. From source, that appears to replace the running override map with that file's contents (INFERRED; not run, because it would disturb a live schedule). A deployment that keeps its config in --config could silently lose its trigger inputs.
3. In our deployment the --config file is a read-only ConfigMap mount, so writing to it is not an option either. trigger set should refuse clearly in that case.

Ask

• workflow.trigger.* should resolve the same config path the server was started with (--config, SWAMP_SERVE_CONFIG, or the default).
• If that path is read-only, trigger set/remove should refuse with the path named rather than write elsewhere.
• trigger get should report the overrides the scheduler actually holds in memory.