feat:report CA

[omnicoder9]

Problem: #9561

Foreman provisions and manages Puppet hosts based on data the agent uploads during a run — both facts (used to create
or update the host record) and reports (used to track ongoing state). Today, that data tells Foreman which Puppet
master the agent contacted (via the server_used field on the report and the implicit master in fact uploads), but it
says nothing about which Puppet CA signed the agent's certificate. In split-CA topologies — where one server compiles
catalogs and a different server handles certificate signing and revocation — Foreman has no reliable way to know which
CA owns a given host. That gap matters at two moments in the host lifecycle: at registration, Foreman can't
auto-assign the correct CA to a new host, so an operator has to set it manually; at deletion, Foreman can't reliably
revoke the host's certificate from the right CA, leaving stale certs behind. Users have asked for the agent itself to
surface this information, since the agent already knows its configured ca_server and ca_port settings, and is the
authoritative source for that mapping.

Solution

We added the agent's configured CA as a first-class field in three places, scoped to the configured CA value (not the
"actually contacted" CA — that would have required threading state out of the HTTP/SSL stack and was deferred). First,
Puppet::Transaction::Report gained a new optional ca_server attribute that serializes as "caname:caport", sitting
alongside the existing server_used field with the same "include only when set" pattern, no report_format bump (it's
purely additive, so older consumers that ignore unknown keys keep working). Second, Puppet::Configurer#run populates
report.ca_server from Puppet[:ca_server]:Puppet[:ca_port] immediately after the report is created, so every report
carries the value regardless of failover, cached-catalog, or apply-mode code paths. Third,
Puppet::Node::Facts#add_local_facts adds a matching ca_server core fact, which is critical because Foreman creates
host records from the first facts upload — before any report exists — so without the fact, the report field alone
wouldn't solve the registration case. The two changes ship together: the fact handles host creation, the report field
keeps the mapping current across runs (e.g. if the CA is reconfigured later). Specs cover all three: round-trip
serialization on the report, configurer population, and the new fact value.