feat(thickness): single Char range field — drop fp.recipe.thickness picker

Per client direction: every order is a thickness RANGE (e.g.
"0.0005-0.0008 mils" or "5-10 mils"), never a single value. The
old picker model (fp.recipe.thickness with a single 'value' Float)
was modelling the wrong concept and overcrowding the order entry
UI. Replaced with one free-text Char field that auto-fills from
last-used or part default.

DELETED entirely:
- fp.recipe.thickness model (file + view + ACL + manifest entry)
- recipe.thickness_option_ids One2many (the picker source)
- "Thickness Options" inline list on the recipe form
- sale.order.line.x_fc_thickness_id (M2O picker)
- account.move.line.x_fc_thickness_id
- fp.delivery.x_fc_thickness_id
- fp.direct.order.line.thickness_id

ADDED:
- sale.order.line.x_fc_thickness_range (Char) — operator types range
- account.move.line.x_fc_thickness_range — for invoice rendering
- fp.delivery.x_fc_thickness_range — for packing slip
- fp.direct.order.line.thickness_range — for the wizard
- fp.part.catalog.x_fc_default_thickness_range — part default

AUTO-FILL CHAIN (sale.order.line + wizard line):
1. Operator already typed → keep
2. Most recent SO line for (this part, this customer) with a
   non-empty thickness_range → copy that
3. part.x_fc_default_thickness_range → copy
4. Blank — operator types

Implemented as both an @api.onchange (interactive) AND a
create() override (programmatic — wizard, sale_mrp bridge,
imports). Same logic in both paths.

WIZARD push-to-defaults: when "Save as Default" toggle is ticked
on a wizard line, persist the line's thickness_range to
part.x_fc_default_thickness_range so future first-customer orders
get a sensible starting point.

REPORTS: customer_line_header.xml + report_fp_wo_sticker.xml now
print the Char range as-typed (no display_name lookup needed).

KEPT (admin documentation only — doesn't affect order entry):
- recipe.thickness_min, thickness_max, thickness_uom on the recipe
  root: documents the recipe's CAPABILITY range. No UI gate; just
  for spec authors to record what the chemistry can produce.

JOB GROUPING: fp.job auto-create groups SO lines by (recipe, part,
spec, thickness, serial). Updated to key on the thickness_range
Char (stripped) instead of the deleted thickness_id integer.

DB cleanup: --update=base ran on the upgrade, dropping the
fp_recipe_thickness table + the four x_fc_thickness_id columns.
Existing data was already nulled in earlier dev work.

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

fusion_plating/fusion_plating_reports/__manifest__.py

@@ -3,7 +3,7 @@
 # License OPL-1 (Odoo Proprietary License v1.0)
 {
     'name': 'Fusion Plating — Reports',
-    'version': '19.0.11.0.0',
+    'version': '19.0.11.1.0',
     'category': 'Manufacturing/Plating',
     'summary': 'PDF reports for Fusion Plating: quote, SO, WO, packing, BoL, CoC, invoice, receipt, quality + compliance.',
     'depends': [

fusion_plating/fusion_plating_reports/report/customer_line_header.xml

@@ -94,9 +94,9 @@
                 <br/>
                 <small>Serial: <span t-esc="line.x_fc_serial_id.name"/></small>
             </t>
-            <t t-if="'x_fc_thickness_id' in line._fields and line.x_fc_thickness_id">
+            <t t-if="'x_fc_thickness_range' in line._fields and line.x_fc_thickness_range">
                 <br/>
-                <small>Thickness: <span t-esc="line.x_fc_thickness_id.display_name"/></small>
+                <small>Thickness: <span t-esc="line.x_fc_thickness_range"/></small>
             </t>
         </t>
         <t t-else="">

fusion_plating/fusion_plating_reports/report/report_fp_wo_sticker.xml

@@ -87,14 +87,11 @@
         <!-- Serial number — Sub 5 added x_fc_serial_id (M2O fp.serial) on
              the SO line. The serial record's `name` is the printable label. -->
         <t t-set="_serial_number" t-value="(_line and 'x_fc_serial_id' in _line._fields and _line.x_fc_serial_id and _line.x_fc_serial_id.name) or '-'"/>
-        <!-- Thickness — Sub 5 added x_fc_thickness_id (M2O fp.coating.thickness)
-             on the SO line. `display_name` is the human-readable range, e.g.
-             "0.3–0.5 mils". The en-dash (U+2013) in display_name mojibakes
-             to "â€"" through wkhtmltopdf's font path on entech, so we
-             swap en-dash + em-dash for a plain hyphen-minus before
-             rendering. ASCII-only printable for any QR-label printer. -->
-        <t t-set="_thickness_dn" t-value="_line and 'x_fc_thickness_id' in _line._fields and _line.x_fc_thickness_id and _line.x_fc_thickness_id.display_name"/>
-        <t t-set="_thickness" t-value="(_thickness_dn and _thickness_dn.replace(u'–', '-').replace(u'—', '-')) or '-'"/>
+        <!-- Thickness — operator-typed Char range, e.g. "0.0005-0.0008 mils".
+             Stored as-typed; ASCII-safe by convention. Strip en/em-dash
+             defensively for the wkhtmltopdf font path on entech. -->
+        <t t-set="_thickness_raw" t-value="_line and 'x_fc_thickness_range' in _line._fields and _line.x_fc_thickness_range"/>
+        <t t-set="_thickness" t-value="(_thickness_raw and _thickness_raw.replace(u'–', '-').replace(u'—', '-')) or '-'"/>
         <!-- Notes content — outer can pre-set this (e.g. the Internal
              variant passes line.x_fc_internal_description). Otherwise
              falls back to line.name (customer-facing description per