EMailed label return generation (alpha)

README.md

@@ -276,9 +276,54 @@ app/
    `_on_export_clicked` calls `export_orders_to_csv`.
 3. Wire it up the same way the JIRA/ShipStation buttons are.
 
+## Emailed return labels (SH007 / OK012)
+
+A different workflow entirely from the normal outbound-kit tickets: a
+customer already has product to return, and needs a return label
+emailed to them. Select a ticket in Active Orders and click **Create
+Return Label**:
+
+- Shows the ticket's **Description** (parsed from JIRA's rich-text
+  format into plain text) - this is where staff note what boxes are
+  needed, so it's visible without opening JIRA.
+- Lets you specify **any number of packages**, each with its own
+  weight and dimensions - replacing the old fixed "1x1x1, 1oz dummy
+  ticket" with real per-request control.
+- Calls ShipStation directly (`POST /v2/labels` with
+  `is_return_label: true`). Confirmed against ShipStation's own
+  return-label docs: **`ship_from` is the customer and `ship_to` is
+  your warehouse** - reversed from every other label this app creates,
+  and easy to get backwards, so this was tested explicitly.
+- `charge_event` is configurable per your risk preference:
+  `on_creation` (pay immediately), `on_carrier_acceptance` (only pay if
+  the customer actually ships it - needs the carrier to enable this on
+  your account first, can take 3-4 weeks), or `carrier_default`.
+
+**This app does not email the label.** Per your workflow, that
+happens from ShipStation itself (Returns tab -> Other Actions -> Send
+Return Label) so it goes out through your branded template - something
+this app couldn't replicate anyway, since ShipStation doesn't expose
+that step through its API as far as I could find. After a label is
+created, the ticket's **Uploaded** checkmark is set (same flag the
+emergency-send feature uses) so you can see at a glance which
+return-label tickets have already had their label created.
+
+Both companies share one physical warehouse but each has its **own
+UPS account** (`SIGNIFY_RETURN_CARRIER_ID` / `OAKSTREET_RETURN_CARRIER_ID`)
+- the return address is the same, just filed under the right company
+name. Occasional shipments to company HQ instead of the shared
+warehouse aren't handled yet - flagged for later, per your note.
+
+**Still an assumption pending confirmation:** the service code
+(`SIGNIFY_RETURN_SERVICE_CODE` / `OAKSTREET_RETURN_SERVICE_CODE`)
+defaults to `ups_ground` since you gave me the carrier/account but not
+a specific service level - change it in Settings if that's not right.
+
 ## Known open item
 
-The **emailed-label SKU** (mentioned but not detailed yet) needs its
-own handling eventually - tell me the SKU and what "done" looks like
-for it when you're ready, and I'll fold it into the terminal-status /
-tracking logic above rather than bolting on something separate.
+You mentioned occasionally shipping return items to a company's
+headquarters instead of the shared warehouse - noted, not built yet
+since you said we could tackle it later. When you're ready, this would
+likely be a dropdown in the Return Label dialog (Warehouse vs. HQ)
+rather than a new settings group, since the workflow is otherwise
+identical.