Fix: Store scaled image URL for file fields when WP 5.3+ big image scaling is active

[masteradhoc]

Fixes #1973

Changes Proposed in this Pull Request

• Added an optional &$actual_url by-reference parameter to create_attachment().
  When WordPress 5.3+ scales a large image during wp_generate_attachment_metadata(),
  the metadata will include original_image and _wp_attached_file will point to the
  -scaled version. actual_url is set via wp_get_attachment_url() in that case,
  giving callers the canonical URL WordPress has stored.

• Moved attachment creation inline within the field loop in update_job_data(), before
  update_post_meta() is called. This ensures wp_generate_attachment_metadata() runs
  first, so any scaled URL is resolved before being persisted to post meta — fixing both
  the served image (full-res was used instead of scaled) and attachment_url_to_postid()
  failures (stored URL didn't match the scaled URL WordPress recorded internally).

Testing Instructions

• Upload an image larger than 2560px (width or height) as a file field on a job listing
  submission form.
• Confirm the value saved in post meta points to the -scaled version of the image, not
  the original.
• Confirm attachment_url_to_postid() returns the correct attachment ID for the stored URL.
• Confirm listings with images under the threshold are unaffected.
• Confirm multi-file fields and the company logo field behave as before.

Release Notes

• Fixed an issue where the full-resolution URL was stored for image file fields when
  WordPress 5.3+ big image scaling was active, causing oversized images to be served and
  breaking attachment ID lookups.

New or Updated Hooks and Templates

Deprecated Code

Screenshot / Video