Move render_js() call to enqueue scripts callback

[agibson-godaddy]

Summary

SV_WP_Job_Batch_Handler::__construct() was calling $this->render_js() directly. Consumers typically instantiate the handler during plugins_loaded (e.g. CSV Export's includes()), so render_js() — which calls ScriptHelper::addInlineScript() → wp_register_script() — ran before admin_enqueue_scripts. As of WP 6.7, that trips a _doing_it_wrong notice on every admin page load.

This PR moves the render_js() call into enqueue_scripts(), which is already hooked to admin_enqueue_scripts in add_hooks() and is also where the script handle the inline JS attaches to is registered.

Story: MWC-20065

Release: #847

Details

• __construct() no longer calls render_js().
• enqueue_scripts() calls render_js() after enqueuing the handler script, so the inline new SV_WP_Job_Batch_Handler(...) snippet is still attached to the right handle and emitted on the same admin pages as before.
• No public API changes; subclasses that override enqueue_scripts() and call parent::enqueue_scripts() (the documented pattern) pick up the new behavior automatically.

QA

Setup

• WordPress 6.7 or newer (so the _doing_it_wrong notice is emitted).
• WP_DEBUG and WP_DEBUG_LOG enabled, or define( 'WP_DEBUG_DISPLAY', true ) so notices surface.
• WooCommerce Customer/Order/Coupon Export plugin installed and active. Point its composer.json at this branch (mwc-20065) and composer update skyverge/wc-plugin-framework so it loads the patched framework copy.
• At least one order exists in the store so an export has something to process.

Steps

1. With the unpatched framework still in place, load any WP admin page (e.g. WP dashboard).
   • debug.log / on-screen notice contains: "Function wp_register_script was called incorrectly... triggered by the wc_customer_order_export_background_export_batch_handler handle." (baseline — confirm the bug reproduces before fixing)
2. Switch the CSV Export plugin to the patched framework branch and reload the same admin page.
   • The _doing_it_wrong notice is gone from debug.log and the page.
3. Go to WooCommerce → Exports → Export, tick Enable batch processing, and run a manual orders export.
   • The progress modal appears and the progress bar advances from 0% to 100%.
   • The export completes and the file downloads (or is delivered per the chosen method).
4. On the same export screen, open browser DevTools → Console and evaluate window.wc_customer_order_export_background_export_batch_handler.
   • It is an instance of SV_WP_Job_Batch_Handler (not undefined). This proves the inline render_js() snippet executed on the page.
5. View page source / Network tab on the export screen and search for new SV_WP_Job_Batch_Handler(.
   • The inline script tag is present in the rendered HTML.
6. Cancel a batch export mid-run via the modal's Cancel button.
   • The job stops and the modal closes cleanly (exercises the cancel_job AJAX path wired up via the same inline JS).

Before merge

• I have confirmed these changes in each supported minor WooCommerce version