[MINOR] Refine request creation into a clear, compact form

[RyanS4]

Summary

Refine the existing request-creation dialog into a readable, compact form with concise labels and a clear sequence of information. Preserve the single-form workflow, catalog selection, conditional fields, validation, totals and submission behavior while reducing nested framing and internal terminology.

Current Behavior

RequestModal.jsx renders a large centered dialog with a gold gradient trim, bordered header, and several nested bordered field groups (L:305-693). Its introductory text says "dynamically configure custom crafted gear or bulk material requests" (L:320), while the primary input is labelled "Target Item from Catalog" beside "155k+ authentic items" (L:344-346). The search placeholder includes four lengthy examples (L:395), and result rows give the internal catalog ID its own right-aligned column (L:403-430).

The selected-item region puts a long item name, category, badge and Change Item button in a tight horizontal structure (L:349-387). Every gear-category selection is labelled "Craftable Gear" (L:364-370), although the display branch is based on the gear-category check at L:196-202; the presentation can use the accurate, shorter "Gear" without changing classification. The fixed-set branch repeats "Set Piece" and "Inherent Set Item" (L:453-464).

Several field labels sound like implementation notes: "Gear & Crafting Attributes," "Material / Item Quantity & Quality," "Offered Gold Bounty (Per Unit)," and "Total Bounty Payout" (L:447, L:562, L:606, L:626). The centered overlay and content scrolling (L:306-307) require review on short screens and with an open search dropdown so the existing form and submit controls remain reachable.

Target Architecture / Expected Behavior

Apply #104's shared form, dialog, typography, spacing, focus and status styles. Retain one form with its existing conditional fields and actions; reorganize only its visible grouping and visual priority. No wizard, new disclosure, new field, new search behavior, validation change, or additional user interaction is part of this issue.

1. Use a clear "Post request" heading, one short instruction, a comfortably sized existing close button and a quiet header. Remove decorative gradient emphasis and unnecessary nested shadows.
2. Organize the existing contents visually into Item, Item details, Offer, and Delivery. Use spacing and section labels rather than a different border/background around every subgroup.
3. Make item-search results easy to compare: item name first, category/subcategory second, internal ID quieter and subordinate. Preserve the displayed identity, the same results, selection target and existing catalog behavior. Retain icon information without enlarging decorative framing.
4. Allow selected item names and their existing metadata to wrap. Give Change item a neutral secondary treatment. Display the fixed set as a concise set summary, preserving the current absence/presence of the optional set selector and all existing values.
5. Use consistent labels and field sizes in the gear and material/item branches. Keep every applicable trait, style, set, quality, level and quantity control, the existing options and their exact values, defaults, visibility rules, and validation unchanged.
6. Clearly associate the offer input with "per item" and display the existing computed total alongside or below it. Keep arithmetic and payload units unchanged; do not introduce estimates or market guidance.
7. Keep the existing handle and optional delivery-note fields easy to read, with concise labels and quiet example text. Keep required/optional meaning and all current validation messages/conditions intact; wording may be shortened only without changing the rules described.
8. Make header, content, dropdown and existing footer usable at short heights and narrow widths. The full form, close, cancel and submit controls must be reachable using the existing interaction model, with no clipped dropdown results or inaccessible offscreen content.
9. Match existing error, searching, disabled and submitting states to the common form styling. Preserve when each state appears, how requests are submitted, and what success and failure do.

Use the following copy direction:

Current wording	Proposed wording
Post Item Request	Post request
Search an item below to dynamically configure custom crafted gear or bulk material requests.	Choose an item and add your offer.
Target Item from Catalog	Item
Search catalog by name (e.g. Rubedite Cuirass, Dreugh Wax, Kuta, Mother's Sorrow)...	Search items
Craftable Gear / Item / Mat	Gear / Item
Change Item	Change item
Gear & Crafting Attributes	Item details
Set Piece: [name] / Inherent Set Item	Set: [name]
Craftable Set Name (Optional)	Crafted set (optional)
No Set (Standard Crafted Base Item)	No set
Style Motif	Style
Target Quality / Item Quality	Quality
Material / Item Quantity & Quality	Item details
Desired Quantity	Quantity
Offered Gold Bounty (Per Unit)	Offer per item
Total Bounty Payout	Total offer
In-Game ESO Handle (@handle)	ESO account name
Optional Delivery Instructions	Delivery notes (optional)
Publish Trade Request / Publishing Request...	Post request / Posting request…

The catalog-size authenticity slogan is redundant form copy and can be removed from the label region. The existing catalog data and authenticity constraints are unchanged. Preserve user-authored notes and item names exactly.

Files Affected

• frontend/src/components/requests/RequestModal.jsx (L:196-243: existing classification, selected-item defaults and traits to preserve; L:245-303: validation and submission payload to preserve; L:305-437: shell, header, item selection and results; L:439-598: conditional gear/material controls; L:600-693: offer, delivery fields and footer).
• frontend/src/pages/RequestBoard.jsx (L:521-529: existing dialog integration and refresh callbacks, for verification only).

Severity & Acceptance Criteria

Severity: MINOR. Queue classification: Tier 3 — UI & User Experience. This is a visual and copy refinement of an existing form.

• The form has a clear hierarchy, short natural labels and fewer nested framed regions, using the shared form/dialog styles from [FEAT] Establish Tailwind v4 design tokens and incrementally migrate core UI #104.
• Catalog search still returns and selects the same items using the same behavior, and all existing item metadata remains available with an intentional visual hierarchy. Long selected names and search results remain readable.
• Every conditional field, option/value, initial default, trait applicability rule, fixed/optional set behavior, quantity and price calculation, validation condition, payload property, API call, authentication rule and success/error action remains unchanged.
• Close, Change item, Cancel and Post request keep their current behavior. No wizard, disclosure, additional field, new search/filter capability, new status, new validation requirement or other user interaction is added.
• Review initial/unselected, searching, populated search results, selected and changed-item states; gear with fixed set, gear with optional set, armour, weapons, jewelry, materials and other items; all current conditional field branches.
• Review price/quantity totals, long names, missing icons, fixed set labels, handle/notes content, validation errors, disabled submit and submitting state. Preserve user-entered content and item identities exactly.
• At 360, 768, 1280 and 1440 CSS-pixel widths, 1280-by-720 and other short-height viewports, and 200% text zoom, the entire form and its existing actions remain reachable. Open-dropdown checks confirm no clipped results, overlapping footer or page-level horizontal overflow.
• Existing relevant unit/integration tests pass with zero errors, and the production frontend build passes. Verify unchanged submission payloads for representative gear and item/material requests. Attach before/after desktop/mobile screenshots with the dropdown open and each form branch; any sample data remains confined to tests.

Dependencies & Blockers

• Blocked By: [FEAT] Establish Tailwind v4 design tokens and incrementally migrate core UI #104.
• Prerequisite For: None.