[Feature]: FakeDataProdModule should populate detector ID in fake frame headers

Description

Discovered when doing work for https://github.com/DUNE-DAQ/daqsystemtest/pull/304

FakeDataProdModule generates fake frame data by zero-initializing a byte buffer of the correct size, leaving all header fields — including the detector ID — as zero. Downstream frame processors validating the detector ID in the frame header would fail when they receive det_id = 0.

Note that two distinct frame header types need to be considered when implementing the fix:

• DAQEthHeader — used by Ethernet-based frames (DAPHNEEth, DAPHNEEthStream, WIBEth). Contains det_id of type DetID::Subdetector_t.
• DAQHeader — used by older/legacy frame types. Needs investigation to determine if the same issue applies and what the correct field/encoding is.

Potential impact radius

Medium

Reason for change

Without this fix, FakeDataProdModule cannot be used as a stand-in for real readout when testing frame types that validate the detector ID.

Suggested implementations

Add a det_id string attribute (using the DetID::subdetector_to_string convention, e.g. "HD_PDS") to FakeDataProdConf in appmodel, defaulting to "Unknown" to preserve existing behavior. In FakeDataProdModule::process_data_request(), after allocating the fake data buffer, iterate over frames and write the correct detector ID into each frame header, conditioned on the configured header type.

Testing suggestions

Create fake data and verify that the det_id is properly set.

Anything else?

This should likely come up as part of the data formats review. (See https://github.com/DUNE-DAQ/daq-deliverables/issues/215)

Start with FakeDataProdConf and FakeDataProdModule::process_data_request(), then compare the DAQEthHeader and DAQHeader cases, including their detector-ID representations. Create fake data for the supported header types and verify that each frame carries the configured detector ID, while preserving the default behavior for "Unknown".