feat(plating): hard-required fields on WO start — operator + bath + tank

User audit caught: in the workforce E2E run we had no idea which bath /
which tank ran the job. For aerospace traceability that's a deal-
breaker. Add a validation gate on mrp.workorder.button_start so
operators can't tap START without the data the shop floor MUST capture.

**Three new pieces on mrp.workorder:**

1. `_fp_is_wet_process()` — best-effort "does this WO involve a
   chemistry bath?" check. Three signals in priority order:
   a. A bath is already linked → definitely wet
   b. The workcenter's FP work-centre supports a wet process family
      (plating, pre/post-treatment, strip, passivation)
   c. WO name contains a wet-process keyword (plat, nickel, chrome,
      anodiz, zinc, etch, clean, rinse, strip, passivat, electroless…)
   The keyword fallback is needed because most existing recipes have
   no process_type_id set on their operation nodes.

2. `_fp_check_required_fields_before_start()` — runs before the
   existing certification check. Rules:
   • Every WO needs an assigned operator (x_fc_assigned_user_id).
     Without it, productivity records can't be attributed and the
     proficiency tracker has no employee to credit.
   • Wet WOs additionally need x_fc_bath_id + x_fc_tank_id. So we
     know exactly which chemistry bath ran the job and which physical
     tank it sat in.
   Raises a clear UserError listing the missing fields if any.

3. `x_fc_requires_bath` (compute, non-stored) — surfaces the wet check
   to the form view so bath + tank fields render with `required=`.

**View changes:**
- `x_fc_assigned_user_id` is now `required="1"` on the form
- `x_fc_bath_id` + `x_fc_tank_id` use `required="x_fc_requires_bath"`
  → red asterisk only when the WO is actually wet

**Simulator updates** (scripts/fp_e2e_workforce.py):
- Hannah now explicitly assigns bath + tank to wet WOs during planning,
  AND pre-issues operator certifications for the bath's process type
  (real shop manager workflow).
- Two negative tests added that PROVE the gates fire:
  • Test 1: strip the operator → button_start raises "missing Assigned Operator"
  • Test 2: strip bath/tank on a wet WO → button_start raises "missing Bath/Tank"

**Final E2E:** 42 PASS / 2 WARN / 0 FAIL out of 44 checks.
Both remaining WARNs (bake-window auto-create, first-piece gate) are
expected behaviour — those are coating-driven and the test coating
intentionally doesn't trigger them.

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

fusion_plating/fusion_plating_bridge_mrp/views/mrp_workorder_views.xml

@@ -93,8 +93,10 @@
                 <field name="x_fc_priority" widget="priority"/>
                 <field name="x_fc_assigned_user_id"
                        string="Assigned To"
+                       required="1"
                        options="{'no_create': True}"/>
                 <field name="x_fc_work_role_id" readonly="1"/>
+                <field name="x_fc_requires_bath" invisible="1"/>
             </xpath>
 
             <!-- ============================================================
@@ -166,8 +168,10 @@
                     <group>
                         <group string="Bath &amp; Tank">
                             <field name="x_fc_facility_id"/>
-                            <field name="x_fc_bath_id"/>
-                            <field name="x_fc_tank_id"/>
+                            <field name="x_fc_bath_id"
+                                   required="x_fc_requires_bath"/>
+                            <field name="x_fc_tank_id"
+                                   required="x_fc_requires_bath"/>
                             <field name="x_fc_rack_id"/>
                             <field name="x_fc_rack_ref"/>
                         </group>