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_quality/views/fp_capa_views.xml

@@ -35,7 +35,7 @@
         <field name="arch" type="xml">
             <form string="CAPA">
                 <header>
-                    <!-- Phase D5 — every state-transition button is QM-only.
+                    <!-- Phase D5 - every state-transition button is QM-only.
                          Per spec section 2.C, Manager has read+comment only;
                          QM owns CRUD + close + effectiveness verification. -->
                     <button name="action_start_analysis" string="Start Analysis" type="object"
@@ -67,7 +67,7 @@
                         <label for="name"/>
                         <h1><field name="name" readonly="1"/></h1>
                     </div>
-                    <!-- Phase D5 — editable fields readonly for non-QM. Per
+                    <!-- Phase D5 - editable fields readonly for non-QM. Per
                          spec section 2.C, Manager retains read+comment only;
                          QM owns CRUD. Form stays visible (Manager needs to
                          read + chatter); only the inputs lock for non-QM. -->