Docs gap or bug: POST /v1/components returns generic HTTP 500 for component_code > ~64KB

## What happened

`POST /v1/components` rejects `component_code` payloads above approximately 64KB (65536 bytes) with a non-actionable error:

```
HTTP/2 500
{ "error": "Unexpected error, please reach out to our team at https://pipedream.com/support" }
```

The 500 returns in ~50ms (X-Runtime 0.048-0.053s), which is way too fast for execution and suggests an API-boundary validator rather than a runtime exception.

## Why this is a bug or docs gap

Neither [Limits](https://pipedream.com/docs/limits) nor the [Component API Reference](https://pipedream.com/docs/components/api) documents any maximum size for `component_code`. The 64KB number that does appear in the docs (the `CONFIGURED_PROPS_SIZE_LIMIT`) applies to configured prop values configured by end users, not the component code itself.

Either:
1. The limit is intentional and should be **documented** (preferred), with a useful 400-class error that surfaces the actual cap and the actual byte size of the rejected payload; or
2. The limit is an unintended consequence of a downstream system (gateway, parser, database column) and should be **fixed** so legitimate component code can grow without a 50ms cliff.

The current behavior makes the failure mode invisible: `node --check` passes locally, the file is valid ES module syntax, and the only signal is a generic 500. Bisecting code vs. comments to find the ceiling wastes maintainer time and burns through deploy attempts.

## Reproduction

Environment: 2026-05-23, REST API via Python `urllib.request.urlopen`, single-component plugin (`$.interface.timer` + `$.interface.http` + `$.service.db`).

I observed the threshold by repeatedly POSTing the same component code with varying amounts of block-comment text shaved off:

| `component_code` bytes | POST /v1/components result |
| --- | --- |
| 39,515 | 200 OK (component created) |
| 51,580 | 200 OK |
| 55,294 | 200 OK |
| 61,689 | 200 OK |
| 67,864 | **HTTP 500** (X-Runtime 0.048s) |
| 69,140 | **HTTP 500** (X-Runtime 0.048s) |
| 69,532 | **HTTP 500** (X-Runtime 0.049s) |
| 72,088 | **HTTP 500** (X-Runtime 0.053s) |
| 72,897 | **HTTP 500** (X-Runtime 0.053s) |

The transition happens between 61,689 and 67,864 bytes. The code in question is identical across rows except for `// ` block comments. Removing comments alone moved a 72KB file under the cap and it deployed. Comments are pure text; nothing about the file's parse output (props, interfaces, methods) changed.

`node --check` passes at all sizes. The component is syntactically valid; the 500 is a Pipedream-side validator decision, not a JS parse failure.

Minimal repro:

```python
import json, urllib.request
code = open("workflow.mjs").read() # > 65KB, valid ES module
req = urllib.request.Request(
"https://api.pipedream.com/v1/components",
headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"},
data=json.dumps({"component_code": code, "org_id": ""}).encode(),
method="POST",
)
urllib.request.urlopen(req) # raises urllib.error.HTTPError 500
```

## Expected behavior

Either:

- The limit is documented (in [Limits](https://pipedream.com/docs/limits), under a new "Component code size" row) AND the API returns `HTTP 413` or `HTTP 400` with a body like `{"error": "component_code exceeds X bytes (got Y)"}`; or
- The cap is raised or removed for the `POST /v1/components` REST endpoint, since component code can legitimately exceed 64KB (the file I was deploying had grown to 72KB after combining two related feature additions, each of which was independently approved in code review).

## Workaround

Strip block comments to get below the cap. This is fragile (comments are a legitimate part of source code, and the cap is invisible until you cross it), so a documented or relaxed limit would be a real improvement.

## Context

I'm building a multi-interface Pipedream source for a SharePoint + Attio + Claude pipeline. The component is intentionally single-file because Pipedream sources don't support local imports. Long-lived sources accumulate inline helpers and design-doc comments; this 64KB-ish ceiling is the kind of thing that's invisible until it isn't.

Request IDs from this session if useful for log search: `abf7b9fc-3167-4ec2-bf17-1446e19929d0`, `d53af5bc-1e3f-4f40-ae2b-013470312e8f`.

cc @PipedreamHQ - would love a docs update or a clearer error, whichever is cheaper on your end.