feat(export): expose include_code_metric_metadata on export_records (HYBIM-788)

[etserend]

Summary

Port of upstream commit e42a569 from rungalileo/galileo-python (#587) — first commit in the HYBIM-788 migration, applied in chronological order.

• Adds include_code_metric_metadata: bool = False param to ExportClient.records() and module-level export_records()
• When True, includes per-row scorer metadata (the dict returned by code-based scorers via the (score, metadata) tuple-return contract) on each MetricSuccess in the export — off by default to keep payloads small
• Patches LogRecordsExportRequest model (log_records_export_request.py) to carry the new field through to_dict() / from_dict()
• Adds 2 tests: default-False and opt-in-True

Namespace translation applied

All galileo.* references rewritten to splunk_ao.* per HYBIM-788 translation rules. galileo-core and galileo_core.* intentionally unchanged (external dep).

Test plan

• poetry run pytest tests/test_export.py -v — 17/17 passed
• poetry run ruff check src/splunk_ao/export.py tests/test_export.py — clean

Part of

HYBIM-788 — commits applied in order: 1 of 3 (e42a569 → fa93ab2 → 6ccd06a)

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — New field was hand-added to generated code without updating openapi.yaml, so it will be silently dropped on the next client regen and break export_records; the author's two blocking Jira questions are also unresolved.

General Comments

• 🟠 major (bug): src/splunk_ao/resources/models/log_records_export_request.py is generated code. scripts/auto-generate-api-client.sh backs up, deletes, and fully regenerates the entire resources/ directory from openapi.yaml with --overwrite, and the LogRecordsExportRequest schema in openapi.yaml (lines 28475-28555) was NOT updated to add include_code_metric_metadata. Consequences on the next regen (HYBIM-853, the 0.29.0 regen the author flagged in the ticket is already pending):

1. The manual include_code_metric_metadata field is dropped from the regenerated model.
2. export.py still passes include_code_metric_metadata=... into the LogRecordsExportRequest(...) constructor (lines 60 and 142), which will then raise TypeError: __init__() got an unexpected keyword argument, breaking export_records() entirely.

The repo already has an established pattern for regen-surviving patches (patch_http_validation_error.py, wired in as a post-generation step). This change uses no such mechanism. Please add the property to the LogRecordsExportRequest schema in openapi.yaml (mirroring the redact entry, with default: false) so it survives regeneration — or, if the intent is to wait for HYBIM-853, coordinate as the author's own ticket question #1 asks before merging. This is the same concern the author raised in HYBIM-788 and it appears to be unanswered.

• 🟡 minor (question): The new field defaults to False rather than UNSET, so to_dict() always emits include_code_metric_metadata: false on every export request (unlike optional fields such as filters/sort which are omitted when unset). This matches upstream and mirrors redact (also default-non-UNSET), but the author explicitly asked in HYBIM-788 whether always sending this field is intended on the backend side, and whether the backend even accepts the field yet. That question is unresolved, and the field is not part of the API contract in openapi.yaml. Please confirm the backend accepts (and does not reject) an unknown/extra field before this ships.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• src/splunk_ao/resources/models/log_records_export_request.py:324-337: Round-trip asymmetry: from_dict defaults include_code_metric_metadata to UNSET when the key is absent, while the constructor/__init__ default is False. So deserializing a payload lacking the key yields UNSET, not False. This is consistent with how openapi-python-client generates other fields and is harmless here, but worth noting if the field is ever added to the spec with a non-UNSET default (regen would produce d.pop(..., False) instead).

[fercor-cisco]

🟠 major (bug): This field was manually added to a file generated by openapi-python-client, but the corresponding property is missing from the LogRecordsExportRequest schema in openapi.yaml. Running scripts/auto-generate-api-client.sh will regenerate this file and silently drop the field, after which the constructor calls in export.py (include_code_metric_metadata=...) will raise TypeError. Add the property to openapi.yaml so the codegen output includes it.

🤖 Generated by the Astra agent

[fercor-cisco]

@etserend were the changes to src/splunk_ao/resources/models/log_records_export_request.py done manually or via the source code generation script?

If they were done manually, they would be lost in the next regeneration.