# WP3 — Issue UX clarity (FE only, no logic change)

## Goal
The partial-issue capability already works (dialog shows planned/consumed/remaining, pre-fills remaining, re-fetches on open — `production-orders.component.ts:882-900`). But the client "couldn't find where to issue the remaining." Make the issue entry point and remaining clearly discoverable, and make the over-issue block message clearer. NO logic change — pure FE clarity.

## Exact files
- FE: `/home/moonui2/public_html/moon-erp/src/app/features/production/orders/production-orders.component.html`
  - List-row issue action is a **bare warn icon** `pi pi-arrow-circle-up` with only a tooltip, buried among ~7 icons (~:120-123). Give it a clear affordance — keep the icon but ensure the tooltip is explicit ("صرف الخامات / Issue materials"), and confirm the detail-view button (~:316-319) has a text label. If a labeled button is easy to add on the list without breaking the action-column layout, do so; otherwise ensure the detail view is the clear path.
  - Issue dialog (~:591-618): confirm the remaining column is clearly labeled and visible.
- FE: `production-orders.component.ts` — the error handler that surfaces `insufficient_stock`. Map the BE `inventory::inventory.messages.insufficient_stock` to a clear localized message ("الرصيد غير كافٍ في المخزن المختار / Not enough stock in the selected warehouse"). Find where issue errors are shown (submitIssueMaterials ~:1051-1074).
- FE i18n: `src/assets/i18n/{en,ar}.json` `PRODUCTION.ORDERS.*` (issue button label/tooltip, insufficient-stock message).

## Behaviour
- No API change, no math change. Only labels, tooltips, and error-message clarity.

## Acceptance criteria
- The issue action is discoverable (explicit tooltip/label); the remaining qty is clearly shown in the dialog and detail view.
- An insufficient-stock error shows a clear localized message, not a raw key.
- `ng build` green.

## Tests
- FE `ng build` green. (No BE tests — FE-only, no logic.)

## Flags
- Not [FIN]. No migration.

## Out of scope
- No change to issue quantities, no cap, no over-issue logic (WP4), no BE changes beyond an optional message key if truly needed.
