meta(refactor-tasks): Add the no-custom-render-helper convention

[ryan953]

Adds a no-custom-render-helper convention to the @sentry/refactor-tasks config, so the daily scan starts reporting test files that hide their JSX behind a local renderFoo() helper, and puts the same guidance in the react-testing skill.

The pattern the rule targets is a helper declared in a spec file whose only job is to forward its arguments into the shared render() / renderGlobalModal() / renderHookWithProviders() helper from sentry-test/reactTestingLibrary. Every file invents its own name and argument shape, so a reader has to go find the helper before any it() block makes sense.

The fix the rule asks for is a component, not an inlined render() call at every call site:

// Before
function renderComponentogprops: LoadingContainerProps = {}) {
  return render(<LoadingContainer {...props}><div>hello!</div></LoadingContainer>);
}

// After
function ExampleLoadingContainer(props: LoadingContainerProps) {
  return <LoadingContainer {...props}><div>hello!</div></LoadingContainer>;
}
// in the test:
const {rerender} = render(<ExampleLoadingContainer isLoading />);

The skill change matters more than the config: the skill is what agents and humans read while writing a test, whereas the scanner config only produces findings after the fact.

Known problem, and why this is a draft

The rule does not work on the scanner's default model. Two -m haiku runs both aborted with a non-JSON reply from the claude-cli backend (Unexpected token 'I', "I already "..., then Unexpected token '<', "<Structure"...), and the run exits 1 while printing a misleading No violations found.. On -m sonnet it returns 58 violations in 82s and exits 0. As a control, no-class-components on the same haiku backend returned 56 violations cleanly, so the backend is healthy and the problem is specific to this rule — most likely its prompt length. The scheduled workflow uses the default model, so this needs sorting before it merges.

What the rule gets wrong today

Running it against master surfaced two gaps worth fixing in the detect text before this lands:

• The setup-helper exemption is written as "and never call render()", which leaves helpers that do both mock setup and rendering undefined. That is what produced the borderline findings in keyRateLimitsForm, releasesSelectControl, transactionReplays/index and gsAdmin/sentryAppDetails.
• Helpers that build render() options from their arguments are flagged, but converting them is a regression: resultGrid#renderGrid would repeat a router-config block across 29 call sites. Same for pageFilters/container, onboardingLayout and relocation.

It also produced one clear false positive: spansTable L163-173 is a JSX-returning arrow that never calls render, which the rule already exempts in prose.

Related

The 42 spec files this rule found and that have already been converted are in #125144. That PR is independent of this one and can land first.

No feature flags. No screenshots — this is a scanner config and a skill doc, with no UI surface.