UX: Disable standard allocation for trackable parts (#11811)

[adityakrmishra]

Fixes #11811.

As discussed in the issue, trackable parts must be allocated via the "Build Outputs" dialog. The previous UI allowed users to click the standard "Allocate" button for trackable parts, which opened a dialog that silently failed to load any stock ("No entries available").

This PR improves the UX by disabling the standard "Allocate" button for trackable items and adding a helpful tooltip directing the user to use the Build Outputs tab instead.

Tested locally and ran the frontend formatter. Let me know if it looks good!

[netlify]

✅ Deploy Preview for inventree-web-pui-preview ready!

Name	Link
🔨 Latest commit	77ccb9b
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/6a0caf094e70660007d439bc
😎 Deploy Preview	https://deploy-preview-11967--inventree-web-pui-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 96 (🟢 up 3 from production) Accessibility: 81 (🔴 down 1 from production) Best Practices: 92 (🔴 down 8 from production) SEO: 78 (no change from production) PWA: - View the detailed breakdown and full score reports
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[matmair]

Lgtm; @SchrodingersGat should we extend the test harness to cover these edge cases?

[adityakrmishra]

Hey @matmair I pushed the update to the Playwright test to assert the button is disabled, but it looks like the pipeline is still tripping up on a QC test

Im having a little trouble interpreting the logs for this specific failure Could you take a quick look? Let me know if this is a known flaky test, or if there's a specific edge case I missed. Any pointers on where to look next would be hugely appreciated!

[adityakrmishra]

@matmair I investigated the Web UI test failure to ensure my changes didn't introduce a regression.
Findings:
The failing test is [firefox] > tests/pages/pui_stock.spec.ts:463:1 > Stock - Tracking.

The changes in this PR are completely isolated to BuildLineTable.tsx and the build allocation logic.
It appears this is an unrelated flaky test specific to the Firefox runner. Could you trigger a re-run of the CI jobs when you get a chance?