refactor(plugin-rsc): convert hooks to nested handler form

[Copilot]

Preparation for #957 by converting all resolveId, load, and transform hooks in plugin-rsc to nested handler form.

Changes

Converted 18 hooks from direct function form to nested handler object:

// Before
resolveId(source) { ... }
load(id) { ... }
async transform(code, id) { ... }

// After
resolveId: {
  handler(source) { ... }
}
load: {
  handler(id) { ... }
}
transform: {
  async handler(code, id) { ... }
}

Affected hooks:

• 5 resolveId hooks (rpc-client, assets-manifest, client-references, encryption-key, css-virtual)
• 7 load hooks (rpc-client, assets-manifest, client-references, client-package, encryption-key, css-virtual, importer-resources)
• 6 transform hooks (load-environment-module, bootstrap-script, use-client, use-server, css-export, importer-resources)

Pure refactoring—no functional changes. Enables hook filtering and composition patterns required by #957.

Original prompt

I'd like to prepare for #957 by first pure refactoring of making all (or most) of (reoslveId/load/transform) to have nested "handler" form
{ name: 'foo', transform() {} } => { name: 'foo', transform: { handler() {} } }

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

General approach: When inserting a stringified value into generated JavaScript source, additionally escape characters that can prematurely terminate a <script> tag or otherwise affect JS parsing. This is done by post-processing the JSON.stringify(...) result before embedding it into source.

Best fix here: Keep defineEncryptionKey as the JSON-stringified key (so functionality and format are unchanged), but sanitize its content before using it in the template literal that returns JS code. We can implement a small, local escaping helper and wrap defineEncryptionKey with it at the sink. This avoids changing the key-generation logic or its storage format and only affects how it is embedded into the virtual module source.

Concretely in packages/plugin-rsc/src/plugin.ts:

• Add a small escapeUnsafeCharsForJs helper near the plugin or in a nearby utilities section that replaces <, >, /, \, control whitespace, \0, and \u2028/\u2029 with safe escape sequences, following the pattern in the background example.

• Change the load.handler branch at line 1684 from:

  return `export default () => (${defineEncryptionKey})`

  to:

  return `export default () => (${escapeUnsafeCharsForJs(defineEncryptionKey)})`

No new imports are required; the helper uses only core JS features. Existing behavior is preserved: we still return a function that, when executed, returns the same string value; only the intermediate source representation is additionally escaped to be safe in all embedding contexts.

---

In general, to fix this class of problem you should not insert raw JSON.stringify output directly into a JavaScript code string that may be embedded in HTML. Instead, you should further escape characters that can break out of a <script> context or introduce parsing surprises (<, >, /, backslash, control characters, and Unicode line/paragraph separators). The fix is to define a small escapeUnsafeChars helper (like in the background example) and apply it to the serialized data before interpolating it.

Concretely for packages/plugin-rsc/src/plugin.ts, we will:

• Add a charMap and escapeUnsafeChars function near the top-level of the file (after existing imports, before isRolldownVite) so it’s available where needed.
• On line 790, wrap the JSON.stringify({ environmentName, entryName }) call with escapeUnsafeChars(...). This preserves the logical content of the JSON while encoding unsafe characters as Unicode escape sequences.
• No other behavior changes: the receiving createRpcClient still gets a JSON string that, when parsed, yields the same object structure.

This requires no new imports; the helper uses only built-in JavaScript features.