feat(orocommerce): release 1.0.0

[mikhail-yahorau]

Description

Makes 1.0.0 the version of the OroCommerce piece that instances install, replacing 0.3.0 as the current
release, per decision record 10.

What is changed

• The piece is offered to instances as 1.0.0; from this version its version number follows semantic
  versioning judged from the consumer's side.
• Flows already pinned to 0.3.0 keep resolving and running against 0.3.0, which stays installed.
• The piece's actions, trigger and behaviour are unchanged; 1.0.0 does what 0.3.0 did.

Impact

• Instances installing the piece from now on install 1.0.0; instances already running it are unaffected
  until someone installs the new version.
• Moving a flow to 1.0.0 is an explicit per-flow re-pin; nothing upgrades on its own.
• No configuration changes or upgrade steps required.

The decision record for this release and the FORK-UPDATE.md §2/§4/§5 updates travel separately in #9,
which documents the branch that owns those files.

How was this tested?

• Built from feb45cdf70 by FORK-UPDATE.md §4 step 3, with the CLI node_modules symlink and --force.
• Artifact sanity-checked before hashing: 67.1 kB with a 177 kB bundled src/index.js and 8 members, so
  not the cached-tsc ~1 KB failure mode that step warns about.
• Rebuilt from a clean worktree of the same commit: byte-identical (cmp).
• bun install --frozen-lockfile succeeds on the committed lockfile.
• turbo run lint --filter=@activepieces/piece-orocommerce passes.
• Edition paths unaffected: this changes no platform code. The piece reaches instances either baked into
  the Oro image as a dev piece or uploaded as a CUSTOM/ARCHIVE piece on Community Edition.

Release identity of the built artifact:

Commit	feb45cdf70
Archive	head-feb45cd-1.0.0.tgz
.tgz sha256	ced1e853f15717b11e8c6282d619c3e0443780c7035c4ced69fbc35915a0663c
Bytes	67 144
package/src/index.js sha256	11ad8876e985a4886be58645474ff5a442eefe4317611ae33feed922faef6cff

Breaking change? (required — CI fails if this is left unedited)

• no — reviewed, not breaking
• yes — technical (removed/renamed API field or endpoint, dropped column, new required field, removed/required env var)
• yes — functional (default/limit/behaviour change, new self-hosted setup step)

No behaviour change for existing flows: piece versions are pinned exactly and coexist, so 0.3.0 keeps
resolving and upgrading is an explicit per-flow action.

Security impact? (required — CI fails if this is left unedited)

• no — reviewed, no security impact
• yes — security-sensitive (call out the risk and mitigation in the description above)