feat(stream_data_on): Save loaded tune file path next to .dat (#52)

[ruck314]

Summary

Closes #52.

Stream-data acquisitions now write a <timestamp>_tune.txt companion file alongside <timestamp>.dat in output_dir, recording the absolute path of the tune file in use at the moment streaming started (or None if no tune has been loaded in the session). This resolves the longstanding ambiguity where the matching tune for a given .dat cannot be inferred from last_tune() once a user has load_tune()'d an older tune.

The new file follows the existing _mask.txt / _freq.txt companion-file pattern in stream_data_on() and is registered with the publisher as a tune_link artifact (distinct from the 'tune' type registered by save_tune, so downstream consumers can tell the two apart).

• Source of truth is self.tune_file, which is set by both save_tune (smurf_tune.py:4250) and load_tune (smurf_tune.py:4298). Falls back to None via getattr if no tune has been touched yet.
• 11-line addition, single hunk in stream_data_on(). No public API change, no behavior change to existing callers.

Test plan

• flake8 --count python/ — 0 errors (matches CI)
• On a SMuRF system: S.load_tune(<old_tune>); S.take_stream_data(1) and confirm <output_dir>/<timestamp>_tune.txt contains the loaded path, not what last_tune() would return
• On a SMuRF system: call take_stream_data with no tune ever loaded; confirm the file is written and contains None
• Verify the publisher emits a tune_link registration alongside mask and data