fix: align safe-plugin-update Step 6 poll with project-scoped endpoint (#6)

[Gmulti]

Summary

Step 6 of the safe-plugin-update workflow polled the global /processes?per_page=20 while Step 7 read from /projects/<ID>/processes?per_page=20. Two problems:

1. Internal inconsistency — same workflow, same processId, two different endpoints.
2. Reliability gap — for accounts with many concurrent processes (agencies managing 50+ sites), the freshly-created processId can drop off page 1 of the global feed within seconds. The select(.id==$PROCESS_ID) then matches nothing, .code // empty returns empty, the poll never sees a terminal state, and the 2-minute loop times out reporting "still queued" even when the update finished in 10 seconds.

-  "https://public-api.wp-umbrella.com/processes?per_page=20" \
+  "https://public-api.wp-umbrella.com/projects/<ID>/processes?per_page=20" \

The project-scoped endpoint avoids the page-1 race because per-project process volume is naturally much smaller, and it now matches Step 7.

Scope

Minimal — only the endpoint URL in Step 6. Two intentional non-changes:

• Polling logic ([ -n "$STATUS" ] truthy exit) is safe-plugin-update polling exits early on any non-empty process code #4 and stays untouched here.
• SKILL.md section 6 still uses the global /processes form as the canonical "track any process" example. The generic guidance stays generic; the project-specific workflow uses the project-specific endpoint.

Build verification

• UMBRELLA_SKIP_COMPRESS=1 bash scripts/build.sh → ✓ Build complete — 8 markdown file(s) copied
• diff -r src/skills skills → empty
• Diff: 2 files (src/ + mirrored skills/), 4 lines total

Test plan

• Trigger a real plugin update via the workflow on a project with several concurrent processes; confirm the poll matches and exits within the 2-minute window
• Verify the timeout message still makes sense (now references the same endpoint as the poll)

Closes #6.