fix(line): warn on inert webhook_host / webhook_port instead of seeding them

[ex-takashima]

Fixes #3328.

Problem

line.settings.webhook_host / webhook_port are declared, defaulted, and env-bound, but nothing reads them. The LINE channel implements WebhookPath() and is mounted as a handler on the shared gateway HTTP server (pkg/channels/manager.go, m.mux.Handle(wh.WebhookPath(), wh)) — it has no listener of its own, so there is no port for it to bind. The only other references are the openclaw importer, a test fixture, and a Web UI label.

The webhook is actually served on gateway.port (default 18790), while every fresh config was seeded with webhook_port: 18791. Both numbers are plausible and adjacent, and nothing distinguishes them. Anyone putting a reverse proxy or tunnel in front of PicoClaw reads the config, points at 18791, and gets a listener that never answers — while channel-enabled, process-healthy, tunnel-connected, and credentials-valid all report fine. The failure surfaces only as webhooks silently 404ing.

Change

Option (1) from the issue — stop advertising them — plus the warning the issue suggests for configs that already set them.

• Defaults (pkg/config/defaults.go): drop both keys from the LINE channel, so new configs no longer advertise a port that is never bound. Only webhook_path remains, which is genuinely honoured.
• Migration (pkg/migrate/sources/openclaw/openclaw_config.go): the importer copied both keys unconditionally, so every migrated config.json got an inert "webhook_host": "", "webhook_port": 0 even when the source never set them. Now carried over only when actually set.
• Struct (pkg/config/config.go): both fields kept, marked Deprecated:, with omitempty added. They are what makes a stale config detectable — that is the only reason to keep them, and they are no longer written back out.
• Warning (pkg/channels/line/line.go): when either is set, log one warning at channel startup naming gateway.host / gateway.port as the real setting, and echo the effective webhook_path.

Net effect: fresh and migrated configs are clean, and a config that still sets these says so out loud instead of failing silently.

Behaviour

Startup with a legacy config carrying both keys:

WARN [line] Ignoring LINE webhook bind settings: the webhook is served by the shared gateway HTTP server
  ignored=webhook_host, webhook_port  use_instead=gateway.host / gateway.port  webhook_path=/webhook/line

Nothing else changes — the fields were inert before this PR and are inert after it. Deleting the fields outright would also have been load-compatible (unknown keys inside a channel settings block are silently ignored, since Settings is a RawNode decoded with a plain json.Unmarshal; only top-level unknown fields are a hard error) — but then a config still setting them would go on being ignored in silence, which is the actual complaint in #3328.

Tests

• TestInertBindKeys — table test over unset / host-only / port-only / both
• TestWebhookPathIgnoresBindSettings — path resolution unaffected by the bind keys
• TestDefaultChannels_LINEOmitsInertWebhookBindKeys — defaults no longer seed them
• TestLINESettings_InertWebhookBindKeysRemainLoadable — a config setting them still decodes
• TestLINESettings_InertWebhookBindKeysNotSerializedWhenUnset — omitempty keeps them out of saved configs
• TestToStandardConfig_LINEOmitsUnsetWebhookBindKeys / TestToStandardConfig_LINEKeepsSetWebhookBindKeys — migration output, both directions

go vet and go test ./pkg/config/... ./pkg/channels/line/... ./pkg/migrate/... pass. (pkg/channels/matrix fails to build in my container for an unrelated pre-existing reason — missing libolm C headers.)

Notes for reviewers

Web UI left alone — web/frontend/src/components/channels/channel-forms/generic-form.tsx still maps webhook_host / webhook_port to "Webhook listening host/port" descriptions. With the keys gone from defaults and migration, the field only renders for configs that already carry it; removing the entries would also orphan the string in ~20 locale files. Happy to fold that in if you'd prefer.

Docs need no change — the issue states these are documented in docs/channels/line/README.md, but no LINE README (en/ja/zh/fr/pt-br/vi) mentions webhook_host, webhook_port, or 18791. The en README already correctly says the shared gateway serves the webhook on 18790.

🤖 Generated with Claude Code