Add EF Core and async safety instructions 🤖🤖🤖

[recsventures-ops]

Adds instructions/ef-core-async-safety.instructions.md for .NET 8+ ASP.NET Core. Generic csharp.instructions.md does not pin sync-over-async, N+1, AsNoTracking, or DTO projection. MIT. No paid product.

[aaronpowell]

Which models has the problem that the instructions are aiming to solve been observed on? I've not come across frontier models having any problems with EF that this skill would solve.

Additionally, there are EF-centric skills in https://github.com/dotnet/skills/tree/main/plugins/dotnet-data that might already tackle some of these problems.

[recsventures-ops]

Thanks @aaronpowell — both points are fair. Models: I have not run a systematic eval against named current frontier models. The failures this file pins (.Result/.Wait(), returning tracked entities from controllers, N+1 from missing Include/Select, skipping AsNoTracking on reads) are ones I still see from Copilot in VS/VS Code and from Cursor/Claude Code on ASP.NET Core work. That is practitioner observation, not a measured “frontier models still fail EF” claim, and I should not have written the file as if it were. If the bar for this repo is named-model repros, I do not have that artifact. dotnet/skills: I read https://github.com/dotnet/skills/tree/main/plugins/dotnet-data. optimizing-ef-core-queries is a skill invoked when a query is already slow (capture SQL, sargability, N+1, split queries). It is better and deeper than this file on query performance. It is not standing always-on applyTo **/*.cs instructions, and it does not pin the async/HTTP-boundary rules (no sync-over-async, CancellationToken, no entity bind/return). csharp.instructions.md in this repo also does not pin those four items. If the overlap is enough that this does not belong here, I will close. If a narrower instructions file (async + HTTP boundary only, drop the EF query section, and point at optimizing-ef-core-queries) would be useful, I can do that instead.