fix(specs): @api.depends on _compute_display_name — fixes 'Unnamed' dropdown

The _compute_display_name method on fusion.plating.customer.spec was
missing its @api.depends decorator. Without it, Odoo doesn't know
when to fire the compute, so display_name stayed NULL on:
- All seeded specs (created via XML data import)
- Any spec created later (the field was never recomputed)

Symptom: Specification dropdown on the SO line showed "Unnamed" for
every option, making spec selection useless.

Fix:
- @api.depends('code', 'revision', 'name') on _compute_display_name
- Imported `api` (was only `fields, models`)

Companion entech-side action: forced recompute on the 15 existing
specs via `env.add_to_compute(specs._fields['display_name'], specs)`
so the stored column was backfilled. New specs created via UI will
trigger the compute automatically going forward.

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

fusion_plating/fusion_plating_quality/__manifest__.py

@@ -5,7 +5,7 @@
 
 {
     'name': 'Fusion Plating — Quality (QMS)',
-    'version': '19.0.6.1.0',
+    'version': '19.0.6.2.0',
     'category': 'Manufacturing/Plating',
     'summary': 'Native QMS for plating shops: NCR, CAPA, calibration, AVL, FAIR, '
                'internal audits, customer specs, document control. CE + EE compatible.',

fusion_plating/fusion_plating_quality/models/fp_customer_spec.py

@@ -3,7 +3,7 @@
 # License OPL-1 (Odoo Proprietary License v1.0)
 # Part of the Fusion Plating product family.
 
-from odoo import fields, models
+from odoo import api, fields, models
 
 
 class FpCustomerSpec(models.Model):
@@ -105,6 +105,7 @@ class FpCustomerSpec(models.Model):
         ),
     ]
 
+    @api.depends('code', 'revision', 'name')
     def _compute_display_name(self):
         for rec in self:
             parts = [rec.code or '']