fix(csharp-codegen): escape C# reserved keywords in generated identifiers

[stablegenius49]

Summary

This PR fixes an issue where C# reserved keywords (like params, class, event, etc.) used as field or parameter names in SpacetimeDB types would cause compilation errors in the generated code.

Problem

When a user defines a table or reducer with a field named using a C# reserved keyword:

[SpacetimeDB.Table]
public partial struct MyTable
{
    public int @params;  // User escapes it in their code
    public string @class;
}

The codegen would generate invalid C# like:

// Generated code (broken)
public int params;  // Error: keyword used as identifier
public void Read(BinaryReader reader) {
    params = ...;  // Error
}

Solution

1. Added an Identifier property to MemberDeclaration in the codegen that automatically detects C# reserved keywords using SyntaxFacts.GetKeywordKind() and prefixes them with @ when needed.

2. Updated all code generation sites to use Identifier instead of Name when generating:

   • Field declarations
   • Property accessors
   • Constructor parameters
   • BSATN serialization code
   • Index accessors
   • Reducer/procedure parameters

3. Added a regression test that verifies tables, reducers, and procedures with keyword field names compile successfully.

Test Plan

• Added CSharpKeywordIdentifiersAreEscapedInGeneratedCode test that creates a table with @class and @params fields, plus a reducer and procedure with keyword parameters
• Existing tests continue to pass (verified locally with FormerlyForbiddenFieldNames fixture which already tests edge cases like Read, Write, GetAlgebraicType)

Fixes #4529

[CLAassistant]

All committers have signed the CLA.

[bfops]

Thank you for opening a PR for this! We'll work on getting it reviewed.

[stablegenius49]

I’ve pushed an update that rebases this PR onto current and resolves merge conflicts while preserving the C# keyword-escaping changes.\n\nWould appreciate a fresh pass when you have a moment. Thanks!

[stablegenius49]

Follow-up correction: rebased onto latest master and resolved conflicts.

[stablegenius49]

CLA is now signed ✅. Could a maintainer please re-run/approve the PR workflows? The latest workflow runs are currently in action_required state from the fork-trigger guard.