fix: gracefully handle CURRENT_USER_HAS_NOT_PINNED_CID on IPFS unpin

[livepeer-tessa]

Problem

When the staging task-runner attempts to delete assets, it calls Pinata's DELETE /pinning/unpin/:cid API. If the CID was pinned under a different service account, Pinata returns:

HTTP 400: {"error":{"reason":"CURRENT_USER_HAS_NOT_PINNED_CID",...}}

This caused the entire asset deletion to fail, leaving 12 assets stuck in the deleting queue (issue daydreamlive/scope#747, detected 2026-03-26 17:31 UTC on staging).

Root cause

The CID ownership mismatch likely resulted from assets being pinned under a different account (possibly due to the 8h API outage on the same day — issue #746) while the task-runner is using a different set of credentials for unpin.

Fix

In clients/ipfs.go, detect the CURRENT_USER_HAS_NOT_PINNED_CID error specifically in Unpin() and return nil instead of propagating the error. Since the CID isn't pinned by the current account, there's nothing to unpin — we log a warning and let deletion proceed.

if errors.As(err, &httpErr) && httpErr.Status == http.StatusBadRequest &&
    strings.Contains(httpErr.Body, "CURRENT_USER_HAS_NOT_PINNED_CID") {
    glog.Warningf("IPFS CID %s not pinned by current account, skipping unpin", cid)
    return nil
}

Tests

Added clients/ipfs_test.go with three cases:

• ✅ CURRENT_USER_HAS_NOT_PINNED_CID → no error (skips unpin gracefully)
• ✅ Other 400 errors → error still propagated
• ✅ Successful 200 → no error

Fixes daydreamlive/scope#747