DealCloud: remove reloadProps/additionalProps from create/update record actions for MCP v3 compatibility

Both DealCloud record actions extend a shared base (`common-create-update.mjs`) that builds inputs dynamically via `additionalProps()`, driven by `reloadProps: true`. Pipedream MCP v3 does not support this pattern: an MCP tool gets a single static JSON Schema resolved once at registration, but `additionalProps()` only computes its props after a parent prop value is known, and there's no round-trip in the MCP tool contract to surface that. The field-level props these actions generate are invisible to an agent, making them broken as MCP tools.

## Affected components (`components/dealcloud`, package `0.2.0`)

| Action | Key | Version | Dynamic mechanism |
|---|---|---|---|
| Create Record | `dealcloud-create-record` | 0.0.1 | `entryTypeId` (reloadProps) → `additionalProps()` fetches entry type fields via `getEntryTypeFields()` and emits one prop per field |
| Update Record | `dealcloud-update-record` | 0.0.1 | Same shared `entryTypeId`-driven per-field prop generation |

A single fix in `common-create-update.mjs` covers both.

Start in components/dealcloud/common-create-update.mjs and trace how reloadProps, additionalProps(), and getEntryTypeFields() serve the create and update record actions. Confirm the static MCP v3 schema constraints and determine how both actions should expose their inputs without the dynamic mechanism. Done means neither action depends on reloadProps or additionalProps and both are compatible with MCP v3.

Written by the indexing model from the issue text.