fix(pinner): restore indirect pin detection and add context cancellation

[lidel]

Follow-up for #1035 (forgot to push local changes):

• Small fix to ensure behavior from before PR feat(pinner): add CheckIfPinnedWithType for efficient checks with names #1035 is exactly the same
  • Sharness in fix: ipfs pin ls <cid> --names kubo#10970 caught this regression

While at it, some cleanup:

• Dry helper traverseIndirectPins to avoid duplicated code
• Added check for context cancellation at the start of each recursive pin
  • It was not present in old code before feat(pinner): add CheckIfPinnedWithType for efficient checks with names #1035, so in theory aborting listing all pins was sometimes stuck for longer than it should

[codecov]

Codecov Report

❌ Patch coverage is 78.43137% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.74%. Comparing base (0cd6062) to head (f73b218).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
pinning/pinner/dspinner/pin.go	78.43%	7 Missing and 4 partials ⚠️

@@            Coverage Diff             @@
##             main    #1039      +/-   ##
==========================================
+ Coverage   60.67%   60.74%   +0.07%     
==========================================
  Files         268      268              
  Lines       33560    33597      +37     
==========================================
+ Hits        20364    20410      +46     
+ Misses      11520    11515       -5     
+ Partials     1676     1672       -4     

Files with missing lines	Coverage Δ
pinning/pinner/dspinner/pin.go	61.09% <78.43%> (+1.77%)	⬆️

... and 12 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lidel]

I've documented the backward-compatibility criteria and confirmed this PR passes legacy sharness tests in:

• fix: ipfs pin ls <cid> --names kubo#10970

I'm going to merge this since #1035 is already in the main branch, we need this PR as well for Kubo 0.38.0-rc1 (ipfs/kubo#10884).

We may want to look at this in the future, maybe the legacy behavior can/should be changed, but I don't want to make any extra waves for 0.38 -- keeping things as-is where possible for now.