Support nested client package layouts in doctor and upgrade docs

[justin808]

Nested client/ Package Layout Follow-Up

What We Found

ifmeorg/ifme keeps its JavaScript dependencies and webpack config under client/ instead of the Rails root.

That layout can still be upgraded successfully to react_on_rails 16.6.0 plus shakapacker 9.6.1, but two rough edges showed up:

1. react_on_rails:doctor still checks the root package.json for react, react-dom, and react-on-rails, even when the real package tree lives under client/.
2. The stock bin/shakapacker flow assumes node_modules/.bin/webpack exists at the Rails root, which is not true for repos that intentionally keep dependencies under client/.

Why It Matters

Older Rails apps often grew a nested frontend directory before the current Shakapacker conventions existed.

If React on Rails wants to make upgrade stories easier for real legacy apps, the docs and diagnostics need a documented path for that layout instead of nudging every repo toward an immediate root-level package rewrite.

Suggested Follow-Up

• Improve react_on_rails:doctor so it can recognize nested package layouts, ideally by honoring configuration that already points React on Rails at the real package location.
• Add upgrade docs showing a supported thin-wrapper pattern for bin/shakapacker, bin/dev, and config/webpack/webpack.config.js when a repo keeps JS under client/.
• Clarify whether Shakapacker itself should support a configurable package root for its binstubs, or whether the wrapper pattern is the intended migration path.

Evidence From The Conversion

• bin/shakapacker --mode development compiled successfully once the repo-aware wrapper targeted client/node_modules/.bin/webpack.
• bundle exec rails react_on_rails:doctor dropped to warnings only after the wrapper files and assets_bundler_config_path were added.
• The remaining warning is about root-level package dependencies, which is a diagnostic mismatch rather than a failing build path.