fix: explain consent-suppressed attribution in Woo order lookup (1.8.16)

[Atroci]

Summary

Closes #44 by making the Order Lookup diagnostics tool self-diagnosing for the exact case that issue reported: an order with empty first_touch/last_touch because marketing consent was denied when the event fired.

• includes/admin/traits/trait-admin-diagnostics-ajax.php (ajax_lookup_woo_order_trace()): reads the order's checkout-time consent snapshot (WooCommerce::CONSENT_META_KEY) and passes it through as lookup.consent_marketing (bool or null if no snapshot was ever recorded, e.g. pre-consent-tracking orders).
• includes/admin/traits/trait-admin-pages.php (render_woo_order_lookup_results()): when a trace's attribution.first_touch/attribution.last_touch are both empty and consent_marketing === false, shows an inline notice explaining why, pointing at Settings → Delivery → Privacy & consent.

Why the order-level consent meta and not the trace's own payload.consent: build_trace_snapshot() doesn't pass consent into the translator, so it falls back to Consent::get_state() — read from the current request's cookie at snapshot-build time. That's accurate for the purchase trace (built in the customer's own request — issue #44's case), but milestone traces built from maybe_dispatch_order_milestone() can fire from wp-admin, cron, or REST, where there's no consent cookie at all, and a no-cookie read also resolves to marketing: false. Keying the notice off that would false-positive on ordinary direct-traffic orders with consent granted. The order-level snapshot (_clicutcl_consent, written once at checkout in save_order_attribution()) is the actual buyer consent and doesn't have that failure mode.

This is a read-only diagnostics change — no consent or attribution capture logic was touched.

Version bumped to 1.8.16 (clicutcl.php Version header + CLICUTCL_VERSION), changelog entries added to changelog.txt and readme.txt. Stable tag in readme.txt intentionally left at 1.8.13 per the existing 3-version WordPress.org buffer policy — this ships to GitHub only for now.

Draft comment for issue #44 (not posted — for Hugo to review/post after merge)

Confirmed: the "Direct" result was correct behavior, not a bug — marketing consent was denied when the event fired, and ClickTrail intentionally gates attribution capture on marketing consent (unlike WooCommerce's own native attribution, which isn't consent-gated). As of this version, the Order Lookup diagnostics tool now explains this directly when it happens, so cases like this are self-diagnosing going forward without needing a GitHub issue. Thanks for the detailed debug payload — it's exactly what made this fix straightforward.

Test plan

• Manually trigger ajax_lookup_woo_order_trace against an order with denied marketing consent at checkout and confirm the notice renders.
• Confirm an order with granted consent, or with no stored consent snapshot at all (pre-existing/legacy orders), does not show the notice.
• Confirm a milestone trace built from an admin-side status change on a consent-granted order does not false-positive.

🤖 Generated with Claude Code