[ENHANCE] Improve Error Reporting in change_password with Printable Context

This issue aims to improve the debuggability of the `change_password` function by adding a printable message to a potential database error. Currently, if the database update fails, a generic `InternalServerError` is returned. By attaching a specific, contextual message, we can make debugging and logging much more effective.


In the [change_password](https://github.com/juspay/hyperswitch/blob/cf30da2df05aac69fd82b676e639b2fbc85dcae5/crates/router/src/core/user.rs#L429) function located in `crates/router/src/core/user.rs`, we update the user's password in the database. The relevant code block is:

If the update_user_by_user_id operation fails (e.g., due to a database connection issue, a constraint violation, etc.), it's wrapped in a [UserErrors::InternalServerError](https://github.com/juspay/hyperswitch/blob/cf30da2df05aac69fd82b676e639b2fbc85dcae5/crates/router/src/core/user.rs#L461). While this correctly signals a server-side problem, the error itself lacks specific context. When debugging, an engineer seeing this error in the logs would have to trace back the execution flow to understand which operation and for which user it failed.

#### __Proposed Solution 💡__

We can enhance this by using the `.attach_printable()` method from the `error-stack` crate. This method allows us to attach a static or pre-formatted string message to the error context.

The goal is to modify the code to include the error message, making it immediately clear what failed during InternalServerError

#### __How to Test Your Changes 🧪__

1. __Make the code change__: Apply the suggested modification to the `change_password` function.

2. __Build the project__: Run `cargo build` or `cargo check` to ensure your changes compile correctly. __If it compiles, the `attach_printable` should work fine.__

3. __Simulate an error (Advanced)__:

   - A good way to test this end-to-end is to:

     1. Create a user via the signup flow.
     2. Log in and get an authentication token.
     3. Call the `change_password` endpoint.

   - To reliably trigger the error for observation, you could temporarily modify the `update_user_by_user_id` method in its respective implementation to always return an error.

   - A simpler way to verify the message is being constructed is to temporarily introduce a `panic!` or a different, guaranteed error inside the `attach_printable` argument to see if it gets hit (remember to remove this temporary change!).

4. __Observe the output__: If you can trigger the error, you should see your new, more descriptive message in the application logs or error response, making it clear that the failure happened during the password update for a specific user.

####


####

<think>
PR Context:
- Title: Update user.rs
- Merged: None
- Files changed: 1 files
- Commits: 1 commits

Implementation approach:
## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [ ] Bugfix
- [x] New feature
- [x] Enhancement
- [ ] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->

Improved error reporting in the `change_password` function by adding a descriptive context message to database errors. This enhancement addresses issue #9641 by making debugging and logging more effective when password update operations fail
</think>

To implement this, you'll need to modify:


(No detailed commit information available)
{"issue_number": 9641, "pr_number": 9645, "commits_count": 0, "files_changed": 1, "response_length": 728, "file_count": 0, "needs_breakdown": false}