feat(plugin): sitemap fetch can skip the staging pin (sitemap.useStagingIp); v0.25.0

[harper-joseph]

What

Adds sitemap.useStagingIp (default true, preserving current behavior). When false, sitemap fetches connect direct to the production origin instead of following staging.ip; the security token header is sent either way. The render/proxy staging passthrough (toggle-header path) is unchanged.

Why

The sitemap refresh reused staging.ip unconditionally — it has no incoming request to carry the staging toggle header, so there was no way to point sitemap fetches at prod while keeping the render/origin-fetch path on the staging edge. The right edge differs per deployment: a token that only authenticates against the staging edge needs the pin, while a token accepted on the production property should fetch the real (prod) sitemap.

How

• The gate lives in util/upstream.js (sitemapStagingIp()) rather than resources/Sitemap.js, which subclasses a live Harper table at import time and is untestable — same reasoning as sitemapRun.js.
• The apply-time staging.ip info message now states where sitemap fetches route, so the effective topology is visible in the logs at startup.
• README: documented the new key and added a staging-passthrough bullet covering the sitemap-fetch behavior and the 403 failure mode of a direct fetch whose token is staging-only.

Tests

node --test: 341 pass, 0 fail (3 new — default follows staging.ip, opt-out goes direct while the render path stays pinned, no-IP is direct regardless of the flag). Lint + format clean.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a new configuration option sitemap.useStagingIp (defaulting to true) to control whether sitemap fetches follow the configured staging.ip or go directly to the production origin. It updates the configuration defaults, documentation, warning messages, sitemap fetching logic, and adds corresponding unit tests. The package version is also bumped to 0.25.0. There are no review comments, and I have no additional feedback to provide.

[harper-joseph]

Context update: kohls already has staging.ip: '' (the token is recognized at the production origin), so sitemap fetches there go direct to prod today and this PR is not a blocker for anything — the daily-refresh enablement went out as a config-only change (kohls-pr#46).

What this PR still buys: the kohls config comment marks the staging line as "load-bearing" precisely because re-enabling staging passthrough (for origin verification) would silently drag the daily sitemap fetch back to the staging edge. With sitemap.useStagingIp the two paths decouple — staging verification can come back without moving sitemap traffic. Default true keeps every existing deployment byte-identical in behavior.