Fix linter errors caused by deprecated attributes.

[ggreer]

No description provided.

[github-actions]

🟠 Bug: roleBuilder does not implement StaticEntitlementSyncerV2 — that interface requires StaticEntitlements(ctx context.Context, opts resource.SyncOpAttrs) ([]*v2.Entitlement, *resource.SyncOpResults, error) (vendored SDK pkg/connectorbuilder/resource_syncer.go:72), and no such method exists anywhere in pkg/. The only entitlement method here is the per-resource Entitlements at line 90, which satisfies ResourceSyncerV2, not this interface. As written the package fails to compile.

Suggested change

	var _ connectorbuilder.StaticEntitlementSyncerV2 = &roleBuilder{}
	var _ connectorbuilder.ResourceSyncerV2 = &roleBuilder{}

[github-actions]

🟡 Suggestion: The bulk of this PR moves profile off the user/group/role/app traits onto Resource.profile, but the only new assertions cover agent status and secret created_at. Nothing asserts r.GetProfile() is populated for users, groups, roles, or NHIs, so a dropped profile in that migration would pass CI silently. Consider adding a require.NotNil(t, r.GetProfile()) (plus a key spot-check) in the user/group/role/NHI tests.

[github-actions]

Connector PR Review: Fix linter errors caused by deprecated attributes.

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 85fdf39b1486.
Review mode: full
View review run: https://github.com/ConductorOne/baton-demo/actions/runs/32758840299

Review Summary

Scanned the full PR diff for security and correctness. This migrates profile, status, and created_at off the deprecated trait fields onto the resource-level WithResourceProfile / WithResourceStatus / WithResourceCreatedAt options across users, groups, roles, NHIs, agents, and secrets; a grep of pkg/ confirms no deprecated trait option remains anywhere in the connector. The prior finding that roles.go:29 asserted StaticEntitlementSyncerV2 is addressed — it now asserts connectorbuilder.ResourceSyncerV2, which roleBuilder satisfies. The prior finding about missing test coverage for the trait-to-resource profile migration still stands: connector_test.go asserts r.GetCreatedAt() and r.GetStatus(), but no test asserts r.GetProfile() for any resource type.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/connector/users.go:131 — dropping WithDetailedStatus lets NewUserTrait apply its own default of STATUS_ENABLED to the deprecated UserTrait.status for every user, so disabled users emit a correct resource-level status alongside an actively wrong trait status.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In `pkg/connector/users.go`:
- Around line 121-136: `userOpts` no longer includes `resource.WithDetailedStatus(...)`.
  Because `resource.WithUserTrait` falls through to `NewUserTrait` when the resource has
  no existing UserTrait annotation, and `NewUserTrait` defaults an unset status to
  `v2.UserTrait_Status_STATUS_ENABLED`, every emitted user now carries a deprecated
  trait status of ENABLED — including users where `u.Enabled` is false. The SDK helper
  `syncUserTraitToResource` only copies trait values onto the resource, never the
  reverse, so `WithResourceStatus(status, statusMessage)` correctly sets the
  resource-level status but leaves the trait field wrong rather than merely unset.
  Compare `pkg/connector/agents.go`, where `WithAgentTrait()` with no options leaves
  the trait status at UNSPECIFIED, which is safe. If any consumer still reads the
  deprecated `UserTrait.status` during the deprecation window, disabled accounts will
  appear active. Fix by re-adding `resource.WithDetailedStatus(status, statusMessage)`
  to `userOpts` with a //nolint:staticcheck comment explaining it is kept for
  backwards compatibility until readers migrate to the resource-level status, or
  confirm and document that no consumer reads the trait status anymore.

[github-actions]

Blocking issues found — see review comments.

stale review

[github-actions]

🟡 Suggestion: Dropping WithDetailedStatus means NewUserTrait applies its own default — UserTrait.status = STATUS_ENABLED — for every user, and the SDK only syncs trait→resource (syncUserTraitToResource), never resource→trait. So a disabled user now emits resource status DISABLED (correct) alongside a deprecated trait status of ENABLED (actively wrong, not merely absent). Contrast agents.go, where WithAgentTrait() leaves the trait status UNSPECIFIED and is therefore safe. If any consumer still reads the deprecated UserTrait.status during the deprecation window, disabled accounts will look active; consider keeping resource.WithDetailedStatus(...) with a //nolint:staticcheck until readers have migrated.

[github-actions]

No blocking issues found.