chore(plating): de-dash shipped code + intake-neutral customer emails

Replace em-dashes and en-dashes with hyphens across 789 shipped source
files (py/xml/js/scss) so the delivered module reads as human-written;
em-dashes had become a recognizable AI-generated tell. Internal .md dev
notes are excluded. The WO-sticker mojibake strippers keep their dash
search targets (now written — / –). No logic changes: comments
and display strings only; validated with py_compile + lxml parse.

Rewrite the 7 customer notification emails to be intake-neutral
(ship-in / drop-off / pickup) and repair-aware, and fix the Shipped
email documents line (packing slip vs bill of lading; certificate only
when issued). Subjects use a hyphen separator.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fusion_plating/fusion_plating_jobs/models/fp_job_rack.py

@@ -3,7 +3,7 @@
 # License OPL-1 (Odoo Proprietary License v1.0)
 # Part of the Fusion Plating product family.
 #
-# Multi-rack splitting at Racking — Phase 1 jobs-module extension.
+# Multi-rack splitting at Racking - Phase 1 jobs-module extension.
 # Core models live in fusion_plating/models/fp_rack_load.py. This file owns
 # everything that touches jobs-module fields (fp.job.step.area_kind,
 # fp.job.part_catalog_id) and the racking-step detection (_fp_is_racking_step).
@@ -30,7 +30,7 @@ class FpRackLoad(models.Model):
     @api.model
     def _fp_racking_step_for(self, job):
         # Detect the racking step by area_kind == 'racking' (the corrected
-        # classification), NOT _fp_is_racking_step() — the latter keys off the
+        # classification), NOT _fp_is_racking_step() - the latter keys off the
         # step's kind, and de-racking steps are frequently mis-tagged
         # kind='racking' in the data, which would wrongly match De-Racking.
         return job.step_ids.filtered(lambda s: s.area_kind == 'racking')[:1]