feat: add configuration JSON schema and sync it from the repo (CFTL-530)

[matyas-jirat-keboola]

Adds the configurationSchema for this component and makes the repository its source of truth.

Part of the KAI JSON-schema coverage effort (CFTL-530 / CFTL-505 / AI-2584).

Why

configurationSchema in the Developer Portal is {} today (app version 52). Two consequences:

• The Keboola MCP server's validation.py skips validation entirely when a component has no
  schema, so configurations written by the in-platform AI assistant and by MCP clients reach
  Storage unchecked.
• The configuration page is a raw JSON editor, so there is nothing guiding a human either.

This component has no custom UI route, so the schema also becomes the config form — see
User-visible change below.

What changed

File	Purpose
component_config/configSchema.json	The draft-07 schema, describing the contents of parameters only
scripts/developer_portal/update_properties.sh	Pushes repo-owned portal properties on a semantic-tag deploy
.github/workflows/push.yml	Runs that script from the existing deploy job
README.md	Documents the script, and that editing the repo file is the durable way to change the live schema

Merging alone changes nothing in the portal — the sync runs on the next semantic-tag release.

Blast radius of the new sync step

The repo had no property sync at all, so this introduces one. It is deliberately narrow:

• It pushes only configurationSchema. Descriptions, documentationUrl/sourceCodeUrl,
  actions, uiOptions, encryption, defaultBucket and everything else are untouched and stay
  portal-owned. Adding any of those later needs a repo-vs-portal diff first, because the repo file
  would start overwriting whatever is live.
• It refuses to push an empty {} / [] document and fails the job instead. The usual
  [ -n "$value" ] guard passes for a 2-byte {} placeholder, which silently wipes a populated
  live property on the next release — that is a real failure mode elsewhere in the org, not a
  hypothetical.
• It does not copy the Python-oriented fn_actions_md_update.sh from other repos. That script
  greps src/component.py, which does not exist here, and under set -e it would abort the deploy.

Behaviour verified locally with docker stubbed: happy path pushes, {} exits 1 before calling the
portal, a missing file is skipped without failing.

How the schema was derived

From src/Keboola/DynamoDbExtractor/Config/ConfigDefinition.php — the component's own Symfony
config tree — cross-read against Extractor.php, Exporter.php, both ReadingAdapters and
CONFIG.md. Notable points:

• db.endpoint, db.accessKeyId, db.#secretAccessKey, db.regionName are all
  isRequired()->cannotBeEmpty() → minLength: 1.
• Per export, id, name, table, incremental and mapping are required; mapping is
  cannotBeEmpty() → minProperties: 1.
• id and limit are integer only — Symfony's integerNode rejects "1", so no string union.
• The scan/query split is encoded as one if/then/else inside exports.items, mirroring
  QUERY_INVALID_NODES and SCAN_INVALID_NODES: dateFilter is rejected in query mode, and the
  four query-only nodes are rejected in scan mode.
• dateFilter requires field + format + value together, matching
  Extractor::validateDateFilter.
• #secretAccessKey is format: password; the examples use an obvious placeholder, never a
  realistic-looking ciphertext.
• No default keys anywhere and no additionalProperties: false, so unknown/legacy keys in stored
  configurations keep validating and nothing gets silently written into existing configs.

Validation

• jsonschema.Draft7Validator.check_schema — passes.
• 17 real configurations from tests/functional — every one accepted (or rejected, for the two
  the component itself rejects) by both jsonschema and the MCP server's
  KeboolaParametersValidator, with 0 undeclared keys. Coverage includes scan, query, query
  with the $ placeholder syntax, secondary-index query, index scan, dateFilter, limit,
  child-table mapping and the native-types manifest case.
• 18 negative tests — each rejected by both validators: query without keyConditionExpression;
  query carrying dateFilter; scan carrying each of the four query-only nodes; mode omitted while
  carrying a query-only node; dateFilter missing a part; missing incremental/mapping; empty
  mapping; missing #secretAccessKey; empty endpoint; mode outside the enum; limit as a
  string; no exports; empty exports.

User-visible change — please read before releasing

Adding a schema turns the configuration page from a raw JSON editor into a generated form. Driven
through the real Keboola RJSF editor, the form renders correctly:

• Field order, tooltips and placeholders as authored; secret masked; id/limit typed as numbers.
• mode, enabled and incremental render as selects with the intended titles (Scan/Query,
  Enabled/Disabled, Full Load/Incremental Load).
• mapping, expressionAttributeNames and expressionAttributeValues (type: "object" +
  format: "editor") render as editable CodeMirror JSON editors and emit parsed objects.
• Mode gating works both ways: index and dateFilter show only in Scan mode; indexName
  (Secondary Index), keyConditionExpression and the two expression-attribute editors show only in
  Query mode. A legacy scan config with no mode key still shows the scan-only fields — the editor
  fills the scan default on load.
• Primary Key renders as a creatable tag picker (type each destination column and press Enter),
  not a stack of add-a-row text inputs. It still stores the same string[].
• Field labels chosen for clarity in the form: name → Output Table Name, index → Index
  (Scan only), value → From Date.

Two things to know before a release:

• The three code-editor fields render without a title label — a bare editor box. This is an
  editor-side limitation (the app's CodeEditorField bypasses the field template); the schema's
  title is correct and is what Kai/MCP read, the form just doesn't paint it. Not fixable from the
  schema.
• Switching an export's mode after entering the other mode's fields leaves the now-hidden values in
  the config. The schema still rejects such a config (Node "…" is not allowed for … export.), and
  so does the component, but the editor does not surface that error prominently. Clearing hidden
  values on mode switch is editor behaviour, out of scope for this schema.

Sanity check before cutting a release: open a real configuration, press Ctrl+D,
paste this schema and confirm a populated mapping survives a save untouched.

Known limitations

• Not cross-checked against production configurations. Validation used the 17 configurations in
  this repo, which cover every documented shape, but not customer data. The one place that would
  bite if a real config is shaped unexpectedly is keyConditionExpression being required in query
  mode — the component does not enforce it, only DynamoDB does, so a stored query export lacking it
  would start being rejected on edit. Every other required entry is enforced by the component.
• db and exports are required at the root even though Symfony tolerates an absent db node;
  both are unconditionally needed for a configuration that can run.
• The portal's longDescription still says the component "must be configured manually" and that you
  "must be familiar with JSON". That is portal-owned and not synced by this PR; worth updating
  separately once the form behaviour above is settled.

🤖 Generated with Claude Code

[linear-code]

CFTL-530

[keboola-pr-reviewer-bot]

Verdict: needs_human (risk 3/5) · profile component-factory

New configurationSchema imposes required constraints unverified against production configs, so a human should confirm no live config breaks.

Impact flags: possible rollback re-introduction — see Check Run summary.

Concerns:

• component_config/configSchema.json: Requires keyConditionExpression in query mode; component doesn't enforce it, unverified vs production configs
• component_config/configSchema.json: New required sets on a live customer-facing component could reject existing configs on edit

Suggested reviewers: @keboola/component-factory