Fix the Dapr guild server build, which breaks the whole solution build

[sven-n]

Master doesn't compile. Building the solution the way the pipeline does — dotnet build --configuration Release -p:ci=true in src — fails on pristine origin/master:

src/Dapr/ServerClients/GuildServer.cs(15,28): error CS0535:
  'GuildServer' does not implement interface member
  'IGuildServer.ChangeGuildMemberPositionByNameAsync(uint, string, GuildPosition, int)'
Build FAILED.
    1 Error(s)

Reproduced in a clean worktree checked out at origin/master, with no other changes present.

Cause

c51d62b ("fix(guild): cross-server role assignment, save-failure restore, role limits") added a fourth parameter int masterTotalLevel to IGuildServer.ChangeGuildMemberPositionByNameAsync for the battle master limit. It was applied to the real implementation and the caller:

• src/GuildServer/GuildServer.cs ✅
• src/GameLogic/PlayerActions/Guild/GuildRoleAssignAction.cs ✅

but not to the Dapr path, which implements the same interface:

• src/Dapr/ServerClients/GuildServer.cs ❌
• src/Dapr/GuildServer.Host/GuildServerController.cs ❌

Why CI didn't catch it before merge

The .NET Core GitHub workflow runs dotnet publish src/Startup/MUnique.OpenMU.Startup.csproj, which doesn't reference the Dapr projects — so a solution that doesn't compile still shows a green check there. Nothing else in the GitHub checks builds the whole solution.

The change

The new parameter is carried through the Dapr path as well, so the remote call behaves like the in-process one:

• GuildMemberRoleChangeByNameArguments gains a MasterTotalLevel field
• the Dapr client takes masterTotalLevel and puts it in the request
• the host controller passes data.MasterTotalLevel on to the guild server

Without this the battle master limit would be silently skipped whenever the guild server runs out of process, so forwarding it is both what makes it compile and what keeps the behaviour consistent.

Verification

Run locally with a .NET 10 SDK, from a clean tree (all bin/obj removed):

• dotnet build --configuration Release -p:ci=true over src/MUnique.OpenMU.sln — 0 errors (the same command reproduces the failure on master without this change)
• dotnet test on every tests/*Tests/*.csproj — all green: AttributeSystem 44 · ChatServer 26 · Network.Packets 608 · Network 73 · Pathfinding 10 · Persistence.Initialization 32 · PlugIns 41 · MUnique.OpenMU 1101 · Web 95

Note: the MUnique.OpenMU Azure check is red on this PR, but that is unrelated — the pipeline is out of credits, so it fails regardless of the code. I originally assumed that red was this compile error, because the "1 errors / 0 warnings" summary matched; that inference was wrong, and merging this will not turn that check green. The compile failure above is real and verified independently of it.

Found while keeping #974 current with master; it is unrelated to that PR, so it's here on its own.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UYEj5xw6iAJKEoDX3hyMZh