Fix transformed Server Function source locations

UPDATE:
After https://github.com/vitejs/vite-plugin-react/pull/1355, the only incorrect mapping is inline directive with Vite 8.
Minimal reproduction is in https://github.com/hi-ogawa/reproductions/tree/main/vite8-inline-hoist-sourcemap-repro

https://github.com/vitejs/vite-plugin-react/pull/1358 revealed some incorrect user-facing source map behaviors. This is to track those issues.

https://github.com/vitejs/vite-plugin-react/blob/9db4976a9f30e89205d327b9e951a0a1d4912fe5/packages/plugin-rsc/e2e/source-map.test.ts#L17-L23

Motivation

Issue #1356 and PR #1358 establish browser-level CDP coverage for development source locations of transformed Server Functions. The resulting expectation matrix records the current behavior and reveals several transforms whose generated registerServerReference(...) callsite does not map to a useful original source position.

This issue tracks fixing those mappings. It is separate from #1356, whose purpose is to establish the fixture and regression infrastructure, and narrower than the transform redesign discussed in #1350.

Current behavior

The source-map E2E currently records these approximate or inaccurate locations:

• Named and anonymous default function exports resolve to the closing brace of the declaration.
• A local export alias resolves to the closing brace of its local function declaration.
• A re-export and expanded export * resolve to the module-level "use server" directive rather than their export statements.
• An inline directive function resolves to the rendered <section> rather than the directive-bearing function.

These expectations intentionally preserve the current state so unrelated changes cannot silently regress working forms. They should be updated as each mapping is corrected.

Expected behavior

Development tooling should navigate to a useful source site for each Server Function:

• Default function exports should resolve to their declaration or export.
• Local aliases should resolve to the local declaration or export specifier.
• Re-exports may resolve to the re-export statement as an acceptable approximation.
• Inline directives should resolve to the directive-bearing function.

Direct named exports, variable exports, TypeScript/TSX exports, multiple exports, default identifier exports, and client-imported Server References already have useful recorded locations and must remain stable.

Implementation context

• transformWrapExport appends registration code for defaults and export specifiers, which can leave the generated call without a useful source mapping.
• transformExpandExportAll feeds the re-export path before wrapping.
• transformHoistInlineDirective moves inline functions and emits registration at the original site, whose composed map currently resolves elsewhere in the component.
• #1350 may change these lowering shapes, but this issue concerns the developer-facing mapping regardless of the generated implementation.

Verification

Update the corresponding current-state expectations in packages/plugin-rsc/e2e/source-map.test.ts while keeping the complete Server Reference matrix passing.

Non-goals

• Establishing the source-map test infrastructure tracked by #1356.
• React Server Action or Server Component error stacks.
• Server console replay.
• React DevTools automation.

Start with packages/plugin-rsc/e2e/source-map.test.ts and its current Server Reference expectation matrix. Trace transformWrapExport, transformExpandExportAll, and transformHoistInlineDirective to understand the mappings for defaults, aliases, re-exports, and inline directives. Update the relevant expectations only when each generated registration callsite maps to a useful source location, while keeping the complete matrix passing.