refactor: use named Permission field in Repository struct instead of anonymous embedding

[Copilot]

The Repository struct in services/context/repo.go embedded access_model.Permission anonymously, causing all permission methods to be promoted directly onto Repository. This made it unclear at call sites whether a method belonged to Repository itself or to its embedded Permission.

Changes

• services/context/repo.go: Replace anonymous access_model.Permission with named field Permission access_model.Permission
• 49 files updated to route permission method calls through the named field:

// Before
ctx.Repo.IsAdmin()
ctx.Repo.CanWrite(unit.TypeCode)
ctx.Repo.CanReadIssuesOrPulls(isPull)
slices.ContainsFunc(unitTypes, ctx.Repo.CanWrite)

// After
ctx.Repo.Permission.IsAdmin()
ctx.Repo.Permission.CanWrite(unit.TypeCode)
ctx.Repo.Permission.CanReadIssuesOrPulls(isPull)
slices.ContainsFunc(unitTypes, ctx.Repo.Permission.CanWrite)

Methods defined directly on *Repository (CanWriteToBranch, CanCreateBranch, etc.) are unchanged.

[wxiaoguang]

"Restrict permission check on repositories and fix some problems (#5314)" made the Permission field anonymous, then the code became difficult to understand or maintain.

This PR introduces a proper name for the field.

ctx.Data["Repo"] = ctx.Repo is also not right, it is useless after #13246, just copy&paste result of PRs like "Correctly handle failed migrations #17575"