feat(portal): inject filter+search strip into Odoo /my/orders + docs

- views/fp_sale_order_portal.xml: new template inherit
  portal_my_orders_fp_search on sale.portal_my_orders. Injects the
  fp_portal_list_controls strip before the "no orders" alert. Filter
  pills + sort dropdown are disabled here (we don't own the route,
  Odoo's sortby is preserved separately). The search input is wired
  to .o_portal_my_doc_table tbody (the table class Odoo's
  portal.portal_table emits) so real-time keyword filtering works
  without needing to monkey-patch the stock route or template.

- CLAUDE.md: documents two conventions surfaced by the recent portal
  work:
    Rule 17 — test scaffolding for account.move creation must use
      with_context(fp_from_so_invoice=True) and pass
      invoice_payment_term_id, to satisfy custom gates in
      fusion_plating_jobs and fusion_plating_invoicing.
    Rule 18 — FP portal list pages don't paginate. They load up to
      500 records and rely on fp_portal_list_search.js to filter
      client-side. Hidden <td class="d-none"> cells per row carry
      extra searchable text.

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

fusion_plating/CLAUDE.md

@@ -174,6 +174,11 @@ These modules have **source code in this repo** but are **intentionally NOT inst
 14. **Sticker template — leave the CSS units alone**: `report_fp_wo_sticker_inner` is calibrated for **px units at paperformat dpi=300** on entech's wkhtmltopdf. Do NOT "modernise" it by converting px→mm or by bumping paperformat dpi — both have been tried (2026-05-16) and both collapsed the layout (tiny logo, tiny QR, body grid shorter than the body band, font sizes visually smaller despite using pt). The math suggests the conversions should be equivalent, but wkhtmltopdf's px↔mm↔dpi mapping doesn't follow the obvious model on this image. Trust the working geometry, change only what you came to change. **Barcode size cap**: Odoo core raises `ValueError("Barcode too large")` when `width * height > 1_200_000` OR `max(width, height) > 10000` (see `base/models/ir_actions_report.py::barcode`). Largest safe square is ~1095×1095 — we use 1000×1000 to stay clear of the ceiling. **Em-dash mojibake**: wkhtmltopdf's default font on entech mojibakes em-dash (—), en-dash (–), smart quotes, and ellipsis into `â€"` etc. — strip them defensively for any free-text field that bleeds into the sticker (thickness, notes, line.name). The strip pattern is `.replace(u'—', '-').replace(u'–', '-')...` in `report_fp_wo_sticker_inner`.
 15. **Recipe editor parity**: Step-level UX features (image attachments, prompt editing, settings toggles, preview affordances, etc.) MUST be implemented in BOTH the **Simple Editor** (`fusion_plating/static/src/{js,xml,scss}/simple_recipe_editor.*` + `controllers/simple_recipe_controller.py`) AND the **Tree Editor** (`fusion_plating/static/src/{js,xml,scss}/recipe_tree_editor.*` + `controllers/recipe_controller.py`). Authors choose between editors per-recipe via `preferred_editor`; if a feature only lands in one, half the userbase silently misses it. Default assumption: most clients use the Simple Editor — when in doubt, ship Simple first, then port to Tree in the same change. Backend model + view changes (e.g. new fields on `fusion.plating.process.node`, new tabs on the node form) automatically reach both editors via the related model — only the editor-specific JS/XML/SCSS needs duplicating.
 16. **HTTP controller route override = method name must match parent**: To override a route on an inherited controller (e.g. `portal.CustomerPortal.home()` at `/my/home`), the override method MUST share the parent's method name. Declaring a new method name with the same `@http.route()` URL does NOT override — Odoo registers BOTH handlers as siblings and the parent typically wins, silently. Pattern: `class FpCustomerPortal(CustomerPortal): @http.route() def home(self, **kw): ...`. Bit us 2026-05-17 in `fusion_plating_portal/controllers/portal.py` — `portal_my_home_dashboard()` failed to override stock `home()`; symptom was the rich FP dashboard never rendering at `/my/home` even though the template was active in DB.
+17. **Test scaffolding — creating account.move in tests**: Two custom gates block direct invoice creation in tests:
+    - `fusion_plating_jobs` blocks all `out_invoice`/`out_refund`/`out_receipt` creates unless `context.get('fp_from_so_invoice')` is set or `invoice_origin` matches an SO name. Bypass: `self.env['account.move'].with_context(fp_from_so_invoice=True).create(...)`.
+    - `fusion_plating_invoicing` blocks `action_post()` when `invoice_payment_term_id` is unset. Bypass: pass `'invoice_payment_term_id': self.env.ref('account.account_payment_term_immediate').id` in the create vals.
+    Both are test-data scaffolding; neither weakens assertions and neither must appear in production code paths.
+18. **Portal list pages — no pagination, 500-record cap**: All FP portal list routes (quote requests, jobs, certifications, deliveries) load up to 500 records and rely on client-side JS filtering. Do NOT re-add `portal_pager` to these routes. The `fp_portal_list_controls` macro + `fp_portal_list_search.js` handle filtering, counting, and the sort dropdown. Hidden `<td class="d-none">` cells inside each row carry extra searchable text (part number, customer PO, contact) that isn't displayed but is matched by the JS.
 
 ## Naming
 - **New custom models** (post-2026-04): `fp.*` prefix (e.g. `fp.part.catalog`, `fp.certificate`)

fusion_plating/fusion_plating_portal/views/fp_sale_order_portal.xml

@@ -14,6 +14,41 @@
 -->
 <odoo>
 
+    <!-- ================================================================== -->
+    <!-- /my/orders — inject filter strip + data-fp-filterable before the -->
+    <!-- Odoo portal table so real-time search works client-side.         -->
+    <!-- Sort dropdown reuses Odoo's existing sortby param; filter pills  -->
+    <!-- link to URL params that Odoo's stock route honours natively.     -->
+    <!-- ================================================================== -->
+    <template id="portal_my_orders_fp_search"
+              inherit_id="sale.portal_my_orders"
+              priority="50">
+
+        <!-- Inject the controls strip right after the portal_searchbar call
+             and before the "no orders" alert / portal_table. The anchor is
+             the <div t-if="not orders"> alert — we inject before it. -->
+        <xpath expr="//div[@t-if='not orders']" position="before">
+            <t t-call="fusion_plating_portal.fp_portal_list_controls">
+                <t t-set="filters" t-value="False"/>
+                <t t-set="active_filter" t-value="'all'"/>
+                <t t-set="sorts" t-value="False"/>
+                <t t-set="active_sort" t-value="'date'"/>
+                <t t-set="search" t-value="''"/>
+                <t t-set="url" t-value="'/my/orders'"/>
+                <t t-set="extra_qs" t-value="''"/>
+                <!-- Odoo's portal.portal_table emits a <table class="o_portal_my_doc_table">
+                     so we don't need to add our own id; the JS just needs a stable selector. -->
+                <t t-set="target" t-value="'.o_portal_my_doc_table tbody'"/>
+                <t t-set="result_total" t-value="orders|length if orders else 0"/>
+                <t t-set="clipped" t-value="False"/>
+            </t>
+        </xpath>
+
+    </template>
+
+    <!-- ================================================================== -->
+    <!-- Sale order portal content: add Part # column                      -->
+    <!-- ================================================================== -->
     <template id="sale_order_portal_content_fp_part_column"
               inherit_id="sale.sale_order_portal_content">