I have an project that takes a two-step process to build an iOS app. There's the native libraries and .dext built in XCode, and then those are linked to a Xamarin project that I use to finish building the app in C# on VisualStudio build. It's simple to link the static libraries in the Xamarin project, and it's simple to embed the .dext to some other native-only app that just in XCode, but I'm not sure how to embed the .dext in the Xamarin project app.
Can you just BundleResource in the Xamarin csproj all of the files in the .dext package (embedded profile, CodeSignature, Info.plist, and the built driver) into a SystemExtension folder in the .ipa? There doesn't seem to be a way to get the signed .dext package from the Xcode build either; the Copy Files "Code Sign On Copy" checkbox is broken for specifically driver dexts.
I don't know about Xamarin, but I can answer parts of your question:
There doesn't seem to be a way to get the signed .dext package from the Xcode build either; the Copy Files "Code Sign On Copy" checkbox is broken for specifically driver dexts.
This is because you really don't want to sign the dext with the same code signing setup as the app. It has its own app ID, entitlements, and corresponding provisioning profile. However, the disabled tickbox just means the dext should already be pre-signed when it comes to embedding it in the app. If you build the dext target on its own in Xcode/xcodebuild, it should already come out signed - if that's not the case, your dext target is misconfigured.
The "copy files" step is for copying items into the target bundle before it's signed, not for copying the built target elsewhere. The "code sign on copy" option individually signs the item(s) copied in, in addition to the whole bundle being signed at the end. So this isn't suitable as a mechanism for copying the built and signed dext into a specific place during your build.
All that is needed to embed the dext should be to copy it into the correct location in your app's bundle, and then sign the app normally (probably with the communicates-with-drivers entitlement).
I can't tell you how that's done with Xamarin, specifically. However, my recommendation would perhaps be an xcodebuild install step for your dext as part of your Xamarin app build. This "installs" the target after build+sign, into $DSTROOT/$INSTALL_PATH. Those variables are Xcode build settings, and can be set per project/target/configuration in the .xcodeproj/project.pbxproj or explicitly on the xcodebuild command line. If you make the DSTROOT a base directory of where Xamarin will look for items to bundle into the app, and the INSTALL_PATH the Library/SystemExtensions, that should solve your problem if I've understood correctly.
I believe on iPadOS there is also a requirement that the dext has a bundle ID that starts with the app ID's bundle ID, so something like: com.example.apps.myapp.drivername if the app's bundle identifier is com.example.apps.myapp. Xcode normally enforces this for you, but if you're assembling your bundle "by hand" there's nothing to check this.