Migrate the rest of python unit tests to conformance tests

[nan-yu]

Description

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.

List which issues are fixed by this PR. For larger changes, raising an issue first helps reduce redundant work.

Pre-launch Checklist

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have added updates to the CHANGELOG.
• I updated/added relevant documentation.
• My code changes (if any) have tests.

If you need help, consider asking for advice on the discussion board.

[gemini-code-assist]

Code Review

This pull request introduces the initial implementation of the A2UI C++ SDK, covering schema management, validation, and a streaming parser. It also expands the shared conformance test suite and updates the Python SDK tests to leverage these new cases. Feedback on the C++ implementation suggests ensuring consistent error handling in catalog selection to match conformance expectations, adopting modern memory management with std::unique_ptr in tests, and using custom delimiters for embedded raw strings to prevent parsing errors. Additionally, improvements were recommended for optimizing component lookup complexity and removing an unused dependency in the CMake configuration.

[nan-yu]

@jiahaog I cannot add you as a reviewer, but feel free to take a look.

I may need to rebase if #1129 is submitted first.

[jiahaog]

lgtm, just minor comments.

[jacobsimionato]

LGTM! The shared validations approach looks fantastic to me.

More general comment about the project: The agent SDKs are growing and maturing quickly with new languages supported and this sophisticated testing infrastructure. I think we should step back and revisit the design soon to make sure it incorporates most of the pressing needs that we are aware of before before scaling to more languages or deeper infra.

My two main concerns are:

• APIs to model different inference strategies in a somewhat interchangeable way
• Integration with rendering SDKs (e.g. the "core" SDK) for the purposes of:
  • Client orchestrated inference
  • Server side rendering, validation, compaction of updates

I just shared draft https://docs.google.com/document/d/1VxcAaUh2sMh14soGVQEkRwz5enA6j4tzDPWJZK9tUqA/edit?resourcekey=0-Ban02LRlWm__B7yOkm8gmA&tab=t.0#heading=h.c0uts5ftkk58 describing the latter

[nan-yu]

LGTM! The shared validations approach looks fantastic to me.

More general comment about the project: The agent SDKs are growing and maturing quickly with new languages supported and this sophisticated testing infrastructure. I think we should step back and revisit the design soon to make sure it incorporates most of the pressing needs that we are aware of before before scaling to more languages or deeper infra.

My two main concerns are:

• APIs to model different inference strategies in a somewhat interchangeable way

• Integration with rendering SDKs (e.g. the "core" SDK) for the purposes of:

  • Client orchestrated inference
  • Server side rendering, validation, compaction of updates

I just shared draft https://docs.google.com/document/d/1VxcAaUh2sMh14soGVQEkRwz5enA6j4tzDPWJZK9tUqA/edit?resourcekey=0-Ban02LRlWm__B7yOkm8gmA&tab=t.0#heading=h.c0uts5ftkk58 describing the latter

I see your point that the underlying architecture would change after integration with the rendering SDK, but I'd still want to get this in to unblock the c++ validator. It also stands as an example on how to set up the test harness.