fix(integrations): persist Fluent Forms attribution metadata

[Atroci]

Intent

Continue ClickTrail improvements after releasing WordPress.org 1.9.1: carry the verified Fluent Forms response_id persistence fix, focused behavioral regression, runtime-safe packaging rules, current WordPress stable metadata, and bounded consent-not-required evidence into the GitHub mainline. Preserve ClickTrail source version 1.10.0 and GitHub v1.10.0 as Latest; do not merge or reuse closed PR #78 as a mainline downgrade. Work from an isolated branch, leave the user's dirty main worktree and separate green PR #79 untouched, validate behavior and packaging, then open a separate reviewable PR with CI.

VIZUH

What Changed

• Persist Fluent Forms attribution metadata through its response_id schema column and add focused regression coverage.
• Add cross-platform release packaging, runtime-manifest validation, stricter development-file exclusions, and Windows package CI.
• Align WordPress 7.1 and WordPress.org 1.9.1 metadata while preserving the 1.10.0 source/GitHub release boundary and documenting bounded Fluent Forms runtime evidence.

Risk Assessment

✅ Low: VIZUH — Change is bounded and preserves Fluent Forms persistence, 1.10.0 mainline versioning, package boundaries, GitHub Latest state, and separate green PR #79.

Testing

Reproduced the base Fluent Forms failure, verified corrected persisted state on PHP 8.1, built and inspected the installable package, confirmed WordPress 7.1 and GitHub Latest v1.10.0 metadata, and validated the Windows CI workflow model; local PowerShell execution remains intentionally owned by subsequent PR CI, and no UI artifact was applicable.

• Evidence: ClickTrail 1.10.0 distributable ZIP (local file: /home/hugocarvalho/.no-mistakes/evidence/01M12R24ZHGKQYY0RDEXBPF14R/click-trail-handler-1.10.0.zip)

Evidence: Fluent Forms before/after evidence

Entry 42 persisted `ct_ft_source=google` and `ct_lt_source=newsletter` in `fluentform_submission_meta` using `response_id=42`. Base commit used incorrect `submission_id`.

Evidence: Package contract evidence

SHA-256 `587ee6098bd3a72fc48b4d110d8df66a69b5436ac901d8e697f9e553f9e365c8`; one `click-trail-handler/` root; runtime manifest present; test manifest and development roots absent.

Evidence: Windows workflow semantic model

Parsed workflow triggers on PR/push to `main` and dispatch; `windows-latest`; pinned checkout; credentials disabled; `npm run make-zip`; PowerShell verification.

- Evidence: [GitHub Latest v1.10.0](https://github.com/vizuh/click-trail-handler/releases/tag/v1.10.0) - Evidence: [Official WordPress version API](https://api.wordpress.org/core/version-check/1.7/) - Outcome: 🔧 1 issue found → auto-fixed ✅ across 2 runs (23m58s)

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 1 issue found → auto-fixed (2) ✅

• ⚠️ RELEASING.md:47 - VIZUH — The newly canonical npm run make-zip path invokes powershell, while its script requires Windows-only robocopy. Linux/macOS release hosts now fail before creating an archive; retain a supported POSIX fallback or provide a cross-platform packager.

🔧 Fix: VIZUH VIZUH — Add cross-platform release packaging dispatcher
1 warning still open:

• ⚠️ tools/release/make-zip.js:65 - VIZUH — makePosixZip() runs rsync before deleting an existing same-version ZIP. If rsync is absent or fails, command exits nonzero but leaves stale archive available for later copy/upload. Delete target before first fallible build command or during failure cleanup.

🔧 Fix: VIZUH VIZUH — Clean failed packaging artifacts
✅ Re-checked - no issues remain.

🔧 **Test** - 1 issue found → auto-fixed ✅

• ⚠️ tools/release/make-zip.ps1 - Windows packaging could not be executed locally because no Windows runtime or PowerShell is available. POSIX packaging is proven; require a Windows CI run if executable evidence for make-zip.ps1 is mandatory before approval.
• git status --short --branch, base-to-target diff, changed-file list, and commit history inspection
• Containerized composer install --no-plugins --no-scripts into transient .test-vendor for focused PHPUnit execution
• PHPUnit selector FluentFormsAdapterTest::test_submission_meta_uses_fluent_forms_response_id_column under PHP 8.1
• Base-commit execution of the same persistence regression; reproduced missing response_id failure
• Containerized PHP 8.1 submission probe showing ct_ft_source, ct_lt_source, and ct_ft_campaign persisted against Fluent entry response_id 9001
• npm run make-zip
• unzip -t dist/click-trail-handler-1.10.0.zip plus executable archive manifest/version assertions
• Official WordPress core version API comparison against packaged Tested up to metadata; confirmed WordPress 7.1
• GitHub latest-release API comparison confirming v1.10.0
• Evidence JSON parsing and ZIP SHA-256 verification

🔧 Fix: VIZUH {"summary":"VIZUH Add Windows package verification workflow"}
✅ Re-checked - no issues remain.

• git diff --name-status c72bc6cd15aad187b63a303f80d45fb446e7f5c2..7d850eb173b9a79d9e848088f8cad8844cc966f5
• PHP 8.1 baseline harness against c72bc6cd15aad187b63a303f80d45fb446e7f5c2
• php vendor/bin/phpunit --configuration phpunit.xml.dist --filter FluentFormsAdapterTest tests/unit/FluentFormsAdapterTest.php inside isolated PHP 8.1 Podman runtime
• PHP 8.1 manual Fluent_Forms_Adapter::on_submission() persistence check
• npm run make-zip
• Executable ZIP inspection using unzip -Z1, unzip -p, JSON parsing, and SHA-256
• PyYAML semantic parse of .github/workflows/package.yml
• Official WordPress Core API and GitHub Releases API checks
• git status --short plus transient-directory cleanup verification

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.