Staff report: APIv3 return is a string, not an array

Previous commit (8ace5f4) passed `return: ["id", "url"]` to APIv3
Attachment.get. APIv3 expects `return` as a comma-separated string
("id,url"); arrays are v4 syntax. Civi caught the type mismatch but
its error-rendering pathway then crashed on htmlentities() (which
was passed the offending array), producing a 500 with an HTML error
page rather than a clean JSON error.

Fix: pass return as "id,url" and add sequential:1 (canonical v3 client
shape — values come back as an array). The civi3 helper already
normalizes either response shape, but sequential matches what real
APIv3 clients send.

Logs to confirm after deploy:
  - Success: no "[staff/report] Attachment.get (v3) failed" warning.
  - File links resolve directly without bouncing off the
    /civicrm/webform-mw/file extension route.

app/api/staff/report/route.ts

@@ -381,7 +381,14 @@ async function buildLivePayload(orgId: number): Promise<StaffReportPayload> {
         {
           // APIv3 takes id as an IN-clause via the {IN: [...]} operator object.
           id: { IN: Array.from(fileIds) },
-          return: ["id", "url"],
+          // APIv3 expects `return` as a comma-separated string. Passing an
+          // array crashes Civi's error pathway on htmlentities() — that's
+          // v4 syntax.
+          return: "id,url",
+          // sequential: 1 forces values to be returned as a plain array
+          // rather than an object keyed by id. The civi3 helper normalizes
+          // either, but the array form is the canonical APIv3 client shape.
+          sequential: 1,
           options: { limit: 0 },
         },
       );