feat(annotation-queues): add annotation queue SDK support (HYBIM-882)

[etserend]

Summary

Ports upstream commit e34a5b19 from rungalileo/galileo-python with all galileo→splunk_ao rebrand translations applied.

Changes

• src/splunk_ao/annotation_queues.py — New 1175-line module: AnnotationQueues SDK class, AnnotationQueue, AnnotationField, AnnotationQueueUser, AnnotationQueueRecordSelector dataclasses, and 16 standalone functions (create_annotation_queue, get_annotation_queue, list_annotation_queues, update_annotation_queue, delete_annotation_queue, share_annotation_queue, add_records_to_annotation_queue, etc.)
• src/splunk_ao/__init__.py — Export all 22 new annotation queue symbols
• src/splunk_ao/integration.py — Switch dispatch from IntegrationName→IntegrationProvider; use integration_db.provider field (upstream refactor)
• src/splunk_ao/project.py — Remove stale created_by docstring references (server-managed field)
• src/splunk_ao/provider.py — Rename _get_integration_name→_get_integration_provider, add LLMIntegration import for models endpoint
• Hand-placed generated files (not produceable by regen workflow — backend spec dropped /annotation_queues/query):
  • resources/api/annotation_queue/query_annotation_queues_annotation_queues_query_post.py
  • resources/models/list_annotation_queue_params.py
• tests/test_integration.py — Update create_mock_integration to set mock.provider alongside mock.name (required by the integration_db.provider-based dispatch introduced in this port)

Upstream reference

rungalileo/galileo-python@e34a5b19 — feat: Add Annotation Queue SDK

Test results

1667 passed, 140 skipped — 0 failures

🤖 Generated with Claude Code

[fercor-cisco]

🤖 This review was auto-generated by Claude Code and reviewed by a human before posting.

Assessment: faithful port of the production code, with two issues to resolve before merge

This PR ports upstream galileo-python commit e34a5b1 ("feat: Add annotation queue SDK support (#623)"). I compared the hand-ported business-logic files patch-for-patch (the autogenerated resources/ client + openapi.yaml are excluded here and flow in via the separate "Update API Client" automation PRs).

✅ What's faithful (no behavior change)

File	Assessment
annotation_queues.py (+1175)	Byte-identical to upstream after galileo→splunk_ao renames — zero non-rename diffs.
__init__.py (+44)	Exact port of the new annotation-queue exports + __all__ entries.
provider.py	Faithful: _get_integration_name→_get_integration_provider, IntegrationName→IntegrationProvider, LLMIntegration(integration_provider.value) wrapping — all match upstream.
integration.py	Faithful: _to_provider keys off integration_db.provider instead of str(name); convenience lookup matches on _get_integration_provider().value; display name preserved separately.

⚠️ Issue 1 — project.py: a behavior change misattributed to this commit

The PR adds the response.type_ sync block to Project.save():

if not isinstance(response.type_, Unset):
    attrs["type"] = response.type_

This block does not belong to e34a5b1. In e34a5b1 it is unchanged context. git log -S shows it was introduced on 2026-03-26 by commit 5d473ed ("feat: implement Project.save() and Dataset.save() (#503)") — ~3.5 months earlier.

What e34a5b1 actually changed in save() was a single line (the request body):

- body = ProjectUpdate(name=self.name, type_=self.type)
+ body = ProjectUpdate(name=self.name)

…and on the splunk-ao side that line was already correct on main. So:

	body = ProjectUpdate(...)	response.type_ sync block
galileo @ e34a5b1	name=self.name	present since March (5d473ed)
splunk-ao main (pre-PR)	name=self.name ✅ already	missing
splunk-ao PR branch	name=self.name (untouched)	added by this PR

The net effect is that this PR back-fills a change from 5d473ed (an earlier commit in the sequence) while labeling it as part of the e34a5b1 port. Project.save() now updates the local type attribute from the server response — a genuine behavior change that did not exist on main, introduced under the wrong commit's banner and without the 5d473ed test that would validate it.

This also reveals that the commit sequence is already out of order upstream of this PR: main has the post-e34a5b1 body but lacks the older March block, which means an earlier port skipped or partially cherry-picked 5d473ed. Recommendation: move the response.type_ block (and ideally the rest of 5d473ed + its tests) into a separate port ordered before this one, and keep this PR to e34a5b1's actual delta.

⚠️ Issue 2 — the test port is incomplete

Upstream e34a5b1 added substantial test coverage that this PR omits:

1. Missing test_annotation_queues.py (1053 lines). 1175 lines of new production code ship with zero accompanying tests.
2. test_integration.py incomplete. Upstream (+71) added a regression test test_property_matches_provider_when_display_name_differs that specifically guards the provider-slug-vs-display-name behavior change in integration.py. It was not ported. Upstream also reworked create_mock_integration to take distinct provider and name params; the PR instead just adds mock.provider = name, so name and provider are always identical in the mocks — which defeats the point of the upstream refactor and can't exercise the new code path.
3. test_project.py not ported. Upstream added assertions that the ProjectUpdate body serializes to exactly {"name": ...}.

🔸 Minor

• UnconfiguredProvider._integration_name → _integration_provider (private str attr) is renamed in this PR but not touched by e34a5b1. Internal and self-consistent, so no behavior change — just a divergence from the source diff.

Bottom line

Production-code behavior for the annotation-queue feature is a faithful, safe port. But before merge: (1) the project.py response.type_ change should be split out and attributed to 5d473ed, and (2) the omitted tests — especially test_annotation_queues.py and the display_name_differs regression test — should be ported so the new behavior is actually covered.

[fercor-cisco]

🤖 This faithfulness review was generated by Claude Code and reviewed by a human before posting.

Faithfulness re-check vs upstream e34a5b19

I re-compared every changed file patch-for-patch against upstream, normalizing the galileo→splunk_ao rebrand. Verdict: the port is faithful and correct — no faithfulness blockers to merge.

Edit: an earlier version of this comment flagged the Splunk-AO-SDK header in the hand-placed query_post.py as a defect. That was wrong — Splunk-AO-SDK is the correct value for this SDK. This comment has been updated to remove that finding. See the follow-up comments for the full retraction.

✅ Correct & complete

File	Result
annotation_queues.py (+1175)	Byte-identical to upstream after rebrand — 0 non-rename diffs.
provider.py	All of e34a5b1's renames match: abstract _get_integration_provider, all 4 concrete providers, LLMIntegration(integration_provider.value) wrapping, LLMIntegration import.
integration.py	Faithful — dispatch keys off integration_db.provider, IntegrationProvider enum, convenience lookup via _get_integration_provider().value.
project.py	Matches e34a5b1 exactly — body = ProjectUpdate(name=self.name), docstring/comment cleanup, and the incorrectly-added response.type_ block was removed (prior review fix).
__init__.py	All 22 annotation-queue symbols imported + in __all__; public API imports resolve.
query_annotation_queues_annotation_queues_query_post.py (hand-placed)	Faithful. The Splunk-AO-SDK header is the correct rebrand for this SDK.
list_annotation_queue_params.py (hand-placed)	Identical to upstream after rebrand.
Tests	test_annotation_queues.py (1053 lines) ported; test_integration.py regression test + reworked create_mock_integration(provider, name=...) present; test_project.py body assertions present. 127 tests pass; all imports resolve.

🔸 Minor divergences (intentional, no behavior change)

• UnconfiguredProvider._integration_name → _integration_provider (provider.py attr + constructor param, and the integration.py._get_integration_by_name param). e34a5b1 did not rename these — it only renamed GenericProvider._integration_name. The branch renamed the UnconfiguredProvider path too, for internal consistency. Self-consistent (no dangling refs), so safe — just extra scope beyond the source diff. Worth a note in the PR description.
• _to_provider inlining (integration.py): branch uses provider.name = str(integration_db.name) inline where upstream introduces a name = str(...) local first. Identical result.

🔹 Pre-existing, out of scope (not introduced by this PR)

• The auto-generated resources/ files repo-wide still emit X-Galileo-SDK for the SDK telemetry header, because the regen tooling hasn't been taught to rebrand it yet. The correct value is Splunk-AO-SDK (which the hand-placed file in this PR uses). Bringing the generated files in line is a separate tooling fix, unrelated to this port.

Bottom line

Business-logic port is faithful and correct; tests are complete and pass. Nothing blocks merge on faithfulness grounds. The only in-PR note is the harmless, self-consistent UnconfiguredProvider._integration_name → _integration_provider extra-scope rename.