Issue:
Bug: [BUG] Setup fail : migration_runner exits with code 1 during standalone setup



### Bug Description

While setting up Hyperswitch locally   using the scripts/setup.sh script, the setup consistently fails during the migration_runner step.

The database (pg) and Redis services start successfully and report as Healthy, but the migration_runner container exits with code 1, causing the setup process to stop.

This blocks local development/testing on Windows environments.


Below is the ss of error :

<img width="930" height="942" alt="Image" src="https://github.com/user-attachments/assets/1578a5d6-323b-4858-8599-fb2cac588804" />

### Expected Behavior

All the containers should have been started and compiled successfully

### Actual Behavior

The error mentioned above occurred 

### Steps To Reproduce

Clone the Repo and run `scripts/setup.sh`


### Context For The Bug

This is my first time setting up  a project this big locally , so i might have miss something , or this might be an actual bug . Either way , i request some help in this matter

### Environment

OS : Windows


### Have you spent some time checking if this bug has been raised before?

- [x] I checked and didn't find a similar issue

### Have you read the Contributing Guidelines?

- [x] I have read the [Contributing Guidelines](https://github.com/juspay/hyperswitch/blob/main/docs/CONTRIBUTING.md)

### Are you willing to submit a PR?

Yes, I am willing to submit a PR!

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 adds the following rule to `.gitattributes` to ensure `.patch` files always use LF line endings, regardless of developer OS:

```gitattributes
*.patch text eol=lf
```

This rule overrides Windows’ default `core.autocrlf` behavior and prevents errors during migration when Diesel’s patch parser encounters CRLF line endings.

**Additionally**: For developers who have already cloned the repository and whose `.patch` files may still have CRLF endings, a workaround :

```bash
git checkout -- crates/diesel_models/drop_id.patch
```

This ensures the `.patch` file is re-checked-out with the correct LF line endings, without requiring a full reclone.

Closes: #9120

### 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).
-->

Diesel’s migration runner fails on Windows because CRLF line endings corrupt the patch file format (e.g., `diff --git a/file.rs b/file.rs\r\n`), causing “invalid char in unquoted filename” parsing errors. By forcing LF endings for patch files via `.gitattributes`, this PR ensures cross-platform consistency and prevents migration failures.

Issue: #9120 

## 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)?
-->
* Applied the change on a Windows environment with `core.autocrlf=true` and confirmed `.patch` files now use `\n` instead of `\r\n`.
* Ran `scripts/setup.sh` and verified that the migration runner no longer exits with code 1.
* Provided the `git checkout -- <patch>` fix to confirm re-checkout resets line endings to LF without recloning.


## Checklist
<!-- Put an `x` in the boxes that apply -->

- [ ] I formatted the code `cargo +nightly fmt --all`
- [ ] I addressed lints thrown by `cargo clippy`
- [x] I reviewed the submitted code
- [ ] I added unit tests for my changes where possible

### Additional Context 

**CRLF vs LF Line Endings Explained**

* **LF (Line Feed)** – used by Unix/Linux/macOS; represented by `\n`
* **CRLF (Carriage Return + Line Feed)** – used by Windows; represented by `\r\n`

Git’s `core.autocrlf=true` (Windows default) can introduce CRLF line endings on checkout and convert them back to LF on commit. Explicit `.gitattributes` configuration (`*.patch text eol=lf`) guarantees LF regardless of platform, preventing CRLF-related parsing issues.

---



Testing:

* Applied the change on a Windows environment with `core.autocrlf=true` and confirmed `.patch` files now use `\n` instead of `\r\n`.
* Ran `scripts/setup.sh` and verified that the migration runner no longer exits with code 1.
* Provided the `git checkout -- <patch>` fix to confirm re-checkout resets line endings to LF without recloning.

Patch:
diff --git a/.gitattributes b/.gitattributes
index 176a458f94e..d7ed342927a 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +1,2 @@
 * text=auto
+*.patch text eol=lf
\ No newline at end of file