feat: upgrade to support SurrealDB v3

[Odonno]

Update SurrealDB integration to support v3:

• hosting container tag updated
• .NET SDK version updated

PR Checklist

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• PR doesn't include merge commits (always rebase on top of our main, if needed)
• Contains NO breaking changes
• Every new API (including internal ones) has full XML docs
• Code follows all style conventions

Other information

• Projects failed to compile due to vulnerabilities on some OpenTelemetry package versions. Also weird OpenTelemetry versioning, needed to pin latest version available on NuGet.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 1294

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 1294"

[aaronpowell]

We've got some merge conflicts @Odonno which is because of the OTEL packages - if you can fix those, when CI goes green it should auto-merge

[Copilot]

Pull request overview

This PR updates the SurrealDB integration in the Aspire Community Toolkit to support SurrealDB v3, adjusting both the hosting container defaults and the sample/test code to work with newer SurrealDb.* client/minimal-API packages.

Changes:

• Bumped SurrealDB/Surrealist container image tags and upgraded SurrealDb.Net / SurrealDb.MinimalApis.Extensions package versions.
• Updated the SurrealDB example API to use the newer Minimal APIs endpoint mapping with session type and adjusted initialization flow.
• Updated centralized OpenTelemetry package versions/pins (with some instrumentation packages explicitly pinned).

Show a summary per file

File	Description
tests/CommunityToolkit.Aspire.Hosting.SurrealDb.Tests/AppHostTests.cs	Reorders API calls so DB initialization happens before querying endpoints.
src/CommunityToolkit.Aspire.SurrealDb/SurrealDbClientSettings.cs	Changes default DI lifetime to Scoped and updates corresponding XML doc.
src/CommunityToolkit.Aspire.Hosting.SurrealDb/SurrealDbContainerImageTags.cs	Updates default container tags for SurrealDB and Surrealist.
examples/surrealdb/CommunityToolkit.Aspire.Hosting.SurrealDb.ApiService/Program.cs	Updates example endpoints and DB initialization logic for new SurrealDb packages.
examples/surrealdb/CommunityToolkit.Aspire.Hosting.SurrealDb.ApiService/Models/WeatherForecastFaker.cs	Improves XML doc wording and removes redundant constructor comment.
examples/surrealdb/CommunityToolkit.Aspire.Hosting.SurrealDb.ApiService/Models/WeatherForecast.cs	Adds table/column mapping attributes.
examples/surrealdb/CommunityToolkit.Aspire.Hosting.SurrealDb.ApiService/Models/TodoFaker.cs	Adds faker for Todo sample data.
examples/surrealdb/CommunityToolkit.Aspire.Hosting.SurrealDb.ApiService/Models/Todo.cs	Adds table/column mapping attributes for Todo.
Directory.Packages.props	Upgrades SurrealDb package versions; pins some OpenTelemetry instrumentation versions.
Directory.Build.props	Bumps OpenTelemetryVersion property used by centralized package versions.

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 4

[aaronpowell]

@Odonno it seems that the TypeScript AppHost is failing here. The logs are saying that the resource isn't starting, so you might need to run it locally and verify/resolve

[Odonno]

For info, Aspire 13.3.0 is unusable on Arch Linux, I have to upgrade to 13.3.5.

[Odonno]

Sometimes the tests works, sometimes they don't. I don't know why at this point.. Could that be related to an issue with Aspire core?

[aaronpowell]

Test instability I think is caused by just the sheer number of runners we start when we do a full test run. While this PR is focusing on the update of SurrealDB, there's also a change the ConformanceTests class in the shared testing library, which then triggers a full test rerun because that is used across most of our tests.

Ideally, that change should be spun off to a separate PR, but I've kicked the runners to go on a second pass.

[Odonno]

Ah, that could explain the strange behavior where the test got triggered a second time before it even finished a first time? I had that behavior sometimes in Debug mode.

[davidfowl]

I think this is mostly a law of large numbers problem. If any one test has even a 0.1% chance of flaking, that sounds fine in isolation, but once you run thousands of tests across lots of runners, those tiny probabilities compound quickly.

And it’s not just the test code. At that scale, we’re also multiplying exposure to network hiccups, disk contention, package feeds, NuGet, npm, Docker pulls, GitHub APIs, and any external service the tests depend on.

Rare failures stop being rare when the system is big enough.

[Odonno]

I agree with that perspective but here the problem is that test failure feels like ~50% for a single test project, for a not so large number of tests (less than 100). Even in the local machine, this is too much IMO. But I know saying this is not helpful at all. I will try to dig more into it when I can.

[aaronpowell]

Looks like some merge conflicts with the 13.4 update @Odonno