Enable telemetry for Bulletin Chain (Westend + Paseo)

[x3c41a]

Bulletin chain specs have telemetryEndpoints: null. Nodes only report to telemetry.polkadot.io if operators manually pass --telemetry-url.

This sets the endpoint in the chain spec itself (verbosity 0). Polkadot, Kusama and Westend relay chains do the same. Every node reports by default. "Westend Bulletin" and "Paseo Bulletin" show up on telemetry.polkadot.io automatically. Operators can opt out with --no-telemetry.

Why not rely on --telemetry-url CLI flag? It makes telemetry opt-in rather than opt-out, so we can't guarantee full network coverage.

Why telemetry and not just Prometheus? Prometheus is per-node (you scrape individual endpoints for deep diagnostics). Telemetry is network-wide (nodes push to a central server) — it answers "how many nodes are online, are they all producing blocks, what versions are they running?" without needing access to each node's metrics port.

[x3c41a]

Note on genesis hash: telemetryEndpoints is a client-side field in the ClientSpec struct (substrate/client/chain-spec/src/chain_spec.rs:294), same category as bootNodes. It does not participate in genesis storage or hash computation. The genesis block is built exclusively from the genesis section of the chain spec via BuildStorage::assimilate_storage(), which never touches client properties. Two nodes with different telemetryEndpoints but identical genesis storage will have identical genesis hashes meaning this change is safe for existing and new nodes.

[nprt]

Note on genesis hash: telemetryEndpoints is a client-side field in the ClientSpec struct (substrate/client/chain-spec/src/chain_spec.rs:294), same category as bootNodes. It does not participate in genesis storage or hash computation. The genesis block is built exclusively from the genesis section of the chain spec via BuildStorage::assimilate_storage(), which never touches client properties. Two nodes with different telemetryEndpoints but identical genesis storage will have identical genesis hashes meaning this change is safe for existing and new nodes.

Makes sense, thanks for the clarification!

I would recommend checking whether the target endpoint makes sense to be used. That is, whether it's current state is good enough for what we expect from it, and if/when there are some expected changes to the endpoint.

Alternatively, I'm ok with setting it as a default value. If we opt for this, I'd leave it to @eduardspa's judgement on Monday.