[Pro] Avoid leaking RSC props through client fetch error messages

[ihabadham]

Summary

React on Rails Pro client-side RSC fetch failures can include serialized component props in thrown error messages.

The browser request still needs to send props to the RSC payload endpoint, but failed-fetch error text should not include the full ?props=... URL because error messages/stacks are commonly captured by consoles, error boundaries, Sentry/Honeybadger, and logs.

Repro

In packages/react-on-rails-pro/src/getReactServerComponent.client.ts, stub fetch to return a non-OK response and call the RSC fetch path with props containing a sentinel:

{ token: 'SECRET_SENTINEL_RSC_PROPS_LEAK' }

Expected:

• fetch is still called with the real URL containing encoded props.
• thrown/logged error text does not contain the sentinel.

Actual:

• failed fetch error text includes the full request URL with ?props=...
• the sentinel appears in the thrown error message/stack.

Impact

Privacy/logging leak, not auth bypass.

Apps should avoid passing secrets in RSC props, but real props can still contain emails, tenant IDs, private filters, tokens, or other user/page data by mistake. Fetch failure paths are exactly the kind of errors that get retained in monitoring tools.

Desired fix

• Keep request behavior unchanged.
• Do not include full fetchUrl with query string in thrown error messages.
• Report the query-free component source/path instead.
• Add regression coverage:
  • sentinel props are present in the actual fetch URL
  • sentinel props are absent from thrown error message/stack
  • retry metadata remains directly readable but is not casually serialized/enumerated