Improve CSS Modules backward compatibility documentation (#809) (#810)

## Summary

Adds comprehensive backward compatibility documentation to the v9
upgrade guide, addressing issue #809. Users upgrading from Shakapacker
8.x to 9.x now have a complete working example showing how to restore
the v8 CSS Modules behavior in large codebases.

## Changes

- Added "Restoring v8 Behavior (Backward Compatibility)" section to the
CSS Modules breaking change documentation
- Included complete working webpack config override example
- Added detailed explanations of each configuration option
- Provided debugging tips for inspecting webpack configuration
- Documented clear migration path from temporary workaround to full v9
adoption
- Referenced real-world example from React on Rails PR #1921

## Key Improvements

1. **Complete working example** - No longer just a reference to other
docs, but a full copy-paste solution
2. **Detailed explanations** - Each configuration option is explained
with comments
3. **Debugging guidance** - Shows how to inspect webpack config
structure
4. **Migration clarity** - Clear steps from v8 behavior to v9 named
exports
5. **Real-world validation** - Links to successful implementation in
React on Rails

## Problem Solved

The previous documentation mentioned overriding CSS Modules
configuration but didn't provide a complete example. Users had to:
- Figure out which webpack config file to modify
- Understand how to iterate through webpack rules
- Determine exact options needed for backward compatibility

This led to runtime failures (components not rendering) that were
difficult to debug since webpack builds succeeded but CSS classes were
undefined at runtime.

## Test Plan

- Documentation change only, no code changes required
- Verified markdown formatting with yarn lint
- Confirmed example matches working solution from React on Rails upgrade

## Related

- Fixes #809
- Referenced implementation:
shakacode/react_on_rails#1921

Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Updated v9 upgrade documentation with detailed webpack configuration
options for CSS Modules. Includes practical code examples for
configuring settings, implementation safety checks, migration guidance,
and best practices to help users maintain compatibility with previous
versions while successfully upgrading to v9.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude <[email protected]>

Author: justin808

docs/v9_upgrade.md

@@ -155,8 +155,74 @@ import * as styles from './Component.module.css';
    This allows you to keep using default imports while migrating gradually
 
 3. **Keep v8 behavior** using webpack configuration (Advanced):
-   - Override the css-loader configuration as shown in [CSS Modules Export Mode documentation](./css-modules-export-mode.md)
-   - Provides more control over the configuration
+
+   If you need more control over the configuration, you can override the css-loader settings directly in your webpack config.
+
+   **Where to add this:** Create or modify `config/webpack/webpack.config.js`. If this file doesn't exist, create it and ensure your `config/webpacker.yml` or build process loads it. See [Webpack Configuration](./webpack.md) for details on customizing webpack.
+
+   ```javascript
+   // config/webpack/webpack.config.js
+   const { generateWebpackConfig, merge } = require("shakapacker")
+
+   const customConfig = () => {
+     const config = merge({}, generateWebpackConfig())
+
+     // Override CSS Modules to use default exports (v8 behavior)
+     config.module.rules.forEach((rule) => {
+       if (
+         rule.test &&
+         (rule.test.test("example.module.scss") ||
+           rule.test.test("example.module.css"))
+       ) {
+         if (Array.isArray(rule.use)) {
+           rule.use.forEach((loader) => {
+             if (
+               loader.loader &&
+               loader.loader.includes("css-loader") &&
+               loader.options &&
+               loader.options.modules
+             ) {
+               // Disable named exports to support default imports
+               loader.options.modules.namedExport = false
+               loader.options.modules.exportLocalsConvention = "camelCase"
+             }
+           })
+         }
+       }
+     })
+
+     return config
+   }
+
+   module.exports = customConfig
+   ```
+
+   **Key points:**
+   - Test both `.module.scss` and `.module.css` file extensions
+   - Validate all loader properties exist before accessing them
+   - Use `.includes('css-loader')` since the loader path may vary
+   - Set both `namedExport: false` and `exportLocalsConvention: 'camelCase'` for full v8 compatibility
+
+   **Debugging tip:** To verify the override is applied correctly, you can inspect the webpack config:
+
+   ```javascript
+   // Add this temporarily to verify your changes
+   if (process.env.DEBUG_WEBPACK_CONFIG) {
+     const cssModuleRules = config.module.rules
+       .filter((r) => r.test?.test?.("example.module.css"))
+       .flatMap((r) => r.use?.filter((l) => l.loader?.includes("css-loader")))
+     console.log(
+       "CSS Module loader options:",
+       JSON.stringify(cssModuleRules, null, 2)
+     )
+   }
+   ```
+
+   Then run: `DEBUG_WEBPACK_CONFIG=true bin/shakapacker`
+
+   **Note:** This is a temporary solution. The recommended approach is to migrate your imports to use named exports as shown in the main documentation.
+
+   For detailed configuration options, see the [CSS Modules Export Mode documentation](./css-modules-export-mode.md)
 
 **Benefits of the change:**