server-nestjs: GitLab group access level defaults to Guest instead of legacy Developer

[shikanime]

Users provisioned into a project's GitLab group land with the wrong default access level when no OIDC role group matches them.

Problem

The legacy GitLab plugin defaulted unmatched project members to Developer: plugins/gitlab/src/members.ts:35 folds role matches with AccessLevel.DEVELOPER as the reduce seed, and addGroupMember/editGroupMember (plugins/gitlab/src/class.ts:545,551) default their accessLevel parameter to AccessLevel.DEVELOPER.

The server-nestjs port changed the fallback: generateAccessLevelMapping in apps/server-nestjs/src/modules/gitlab/gitlab.utils.ts:82 seeds unmapped users with AccessLevel.GUEST, so a member with no matching OIDC group is downgraded from the legacy Developer behavior.

Impact: existing users whose OIDC memberships no longer match any configured role-group suffix silently lose Developer rights on their project group (push, pipeline trigger), breaking legacy parity for migrated projects.

Acceptance

• generateAccessLevelMapping assigns AccessLevel.DEVELOPER to a user with no matching role OIDC group, verified by pnpm vitest run covering the no-match case in the gitlab module suite
• GitLab group membership sync (ensureGroupMemberAccessLevel) no longer downgrades an existing Developer member to Guest when the mapping yields no match, verified by the same suite
• Full apps/server-nestjs test suite passes: pnpm vitest run exits 0

References

• PR fix: mitigation on GitLab legacy default permissions #2681 (one-line mitigation: fallback GUEST → DEVELOPER)
• Legacy default: plugins/gitlab/src/members.ts:35, plugins/gitlab/src/class.ts:545-554
• NestJS mapping: apps/server-nestjs/src/modules/gitlab/gitlab.utils.ts:63-90

[shikanime]

Root cause (post-convergence finding)

Legacy seeded unmatched members at Developer; the NestJS port seeded them at Guest.

• - acc.set(membership.user.id, highest ?? AccessLevel.GUEST)
• + acc.set(membership.user.id, highest ?? AccessLevel.DEVELOPER) (PR fix: mitigation on GitLab legacy default permissions #2681 mitigation)

Legacy equivalents: plugins/gitlab/src/members.ts:35 (reduce seed AccessLevel.DEVELOPER) and plugins/gitlab/src/class.ts:545,551 (default parameter AccessLevel.DEVELOPER on addGroupMember/editGroupMember). PR #2681 restores the legacy fallback in apps/server-nestjs/src/modules/gitlab/gitlab.utils.ts:82; the ledger here covers regression-test coverage for the no-match case and the sync-downgrade path.

[shikanime]

Ledger evidence (PR #2681, head caee88e8)

Criterion 1 — no-match fallback is DEVELOPER:
apps/server-nestjs/src/modules/gitlab/gitlab.utils.ts:85 changed - acc.set(membership.user.id, highest ?? AccessLevel.GUEST) → + acc.set(membership.user.id, highest ?? AccessLevel.DEVELOPER).
Covered by gitlab.service.spec.ts "should create gitlab user if not exists" (now expects addGroupMember(group, 999, AccessLevel.DEVELOPER)) and the role-mapping suite.

Criterion 2 — no downgrade of unmatched members:
gitlab.service.spec.ts "should downgrade existing member to developer when no role maps to an access level" now asserts editGroupMember(group, 105, AccessLevel.DEVELOPER) and removeGroupMember not called. This test initially failed against the stale GUEST expectation and was updated in commit caee88e8.

Criterion 3 — suite passes:
Local: pnpm vitest run src/modules/gitlab/gitlab.service.spec.ts → 22/22 passed.
CI run 34131872125 on head caee88e8 (full apps/server-nestjs suite in the unit-tests job): SUCCESS, rollup on the head is 32 SUCCESS / 2 SKIPPED / 0 failures.

Residual observation (non-blocking, out of ledger scope)

apps/server-nestjs/src/modules/gitlab/gitlab.service.ts:198 keeps a second fallback accessLevelByUserId.get(user.id) ?? AccessLevel.GUEST for users absent from the mapping. The mapping covers every project member, and owners are added separately with AccessLevel.OWNER, so this path is not reachable for ledger scenarios — flagging it here for a future parity pass rather than expanding this PR's scope.