Issue:
Bug: Deleting a user role and again assigning a role to user is not updating its previous role to new role



Role id is not getting updated in the invited user account in case the role is deleted and assigned again to invited user. This is happening due to the lineage context stored in db not updating the role id in case that role id does not exist any more.

Steps to duplicate this edge case:  
1. Invite a user with any user role
2. Accept the invitation and login to invited user account
3. Delete the user role from the account who invited the user 
4. Assign a user role, then try to login to the invited account
5. Invited account still operates on the previous user role because of the lineage context getting stored in db

Pull request description:


## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [x] Bugfix
- [ ] New feature
- [ ] Enhancement
- [ ] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->
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

<!--
Provide links to the files with corresponding changes.

Following are the paths where you can find config files:
1. `config`
2. `crates/router/src/configs`
3. `loadtest/config`
-->


## Motivation and Context
<!--
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here.

If you don't have an issue, we'd recommend starting with one first so the PR
can focus on the implementation (unless it is an obvious bug or documentation fix
that will have little conversation).
-->
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?
<!--
Did you write an integration/unit/API test to verify the code changes?
Or did you test this change manually (provide relevant screenshots)?
-->
#### 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
<!-- Put an `x` in the boxes that apply -->

- [x] I formatted the code `cargo +nightly fmt --all`
- [x] I addressed lints thrown by `cargo clippy`
- [x] I reviewed the submitted code
- [x] I added unit tests for my changes where possible


Testing:

#### 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`.

Patch:
diff --git a/crates/router/src/types/domain/user/decision_manager.rs b/crates/router/src/types/domain/user/decision_manager.rs
index 7bc11383da0..15d5463ecff 100644
--- a/crates/router/src/types/domain/user/decision_manager.rs
+++ b/crates/router/src/types/domain/user/decision_manager.rs
@@ -158,7 +158,11 @@ impl JWTFlow {
                         UserRoleVersion::V2,
                     )
                     .await
-                    .is_ok();
+                    .inspect_err(|e| {
+                        logger::error!("Failed to validate V2 role: {e:?}");
+                    })
+                    .map(|role| role.role_id == ctx.role_id)
+                    .unwrap_or_default();
 
                 if user_role_match_v2 {
                     ctx
@@ -174,7 +178,11 @@ impl JWTFlow {
                             UserRoleVersion::V1,
                         )
                         .await
-                        .is_ok();
+                        .inspect_err(|e| {
+                            logger::error!("Failed to validate V1 role: {e:?}");
+                        })
+                        .map(|role| role.role_id == ctx.role_id)
+                        .unwrap_or_default();
 
                     if user_role_match_v1 {
                         ctx