fix(users): fallback to fresh lineage context if cached role_id no longer matches

[tsdk02]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

This PR fixes an issue where a stale role_id from the cached lineage_context was being used to generate the JWT token during sign-in, even if the actual user role was modified (e.g., role deleted and recreated with a different role_id but same lineage).

Previously, we only validated if a user role existed for the lineage (user_id, tenant_id, org_id, merchant_id, profile_id), but did not verify that the role_id matched the current assigned role. This led to JWTs being issued with outdated role_id values.

Changes Made

• During sign-in, added a strict match check for role_id in the fetched user role.
• If the role_id from cached lineage_context does not match the current role fetched from DB (v2 fallback to v1), we now resolve the lineage afresh from the current user_role object.
• Logged errors for failed role fetch attempts for better traceability.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

In systems where roles can be modified dynamically (e.g., deleted and recreated), relying on cached lineage_context.role_id without validating it introduces a silent inconsistency. This can lead to:

• Unexpected authorization behavior
• Hard-to-debug permission issues
• Stale tokens being issued

This fix ensures that JWTs are always generated using valid and current role_id information associated with the user role.

How did you test it?

Scenario: Validate fallback when role_id has changed

1. Initial Setup

   • Log in as an org_admin of Org A.
   • Invite User X to Org A with the role org_admin.
   • Ensure User X is also part of another organization (Org B) and has a valid user role there.

2. Initial Sign-In

   • Sign in as User X to Org A, selecting a specific merchant and profile.
   • This populates and stores the lineage_context based on the selected values.

3. Modify Role Assignment

   • Log back in as the original org_admin of Org A.
   • Delete the current user role (org_admin) of User X in Org A.
   • Create a new role in Org A named profile_admin using the same merchant and profile from the stored lineage_context.
   • Re-invite User X to Org A with this new profile_admin role.

4. Re-Sign-In Validation

   • Now sign in again as User X.
   • Since the original role (org_admin) no longer exists, the cached lineage context will fail validation.
   • The system should fall back to the default sign-in flow and pick a valid user role for JWT construction.

5. Verify Correct Role Assignment

   • If sign-in occurs into a different organization, it's acceptable.
   • If signed into Org A, validate the role_id:
     • Check the response from /user API.
     • OR decode the JWT token.
   • The role_id should now correctly reflect profile_admin.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/types/domain/user/decision_manager.rs	25% smaller

[ThisIsMani]

I don't think this is needed.

[racnan]

https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or