ref(spring): [Cache Tracing 15] Use method-specific span operations for cache spans

[adinauer]

PR Stack (Cache Tracing)

• #5172 — Add SentryCacheWrapper and SentryCacheManagerWrapper
• #5173 — Add enableCacheTracing option
• #5174 — Add BeanPostProcessor and auto-configuration
• #5175 — Add cache tracing e2e sample
• #5179 — Add SentryJCacheWrapper for JCache (JSR-107)
• #5182 — Add JCache console sample
• #5183 — Add cache tracing to all Spring Boot 4 samples
• #5184 — Add retrieve() overrides for reactive/async cache support
• #5190 — Port cache tracing to Spring Boot 3 Jakarta + samples
• #5191 — Port cache tracing to Spring Boot 2 + samples
• #5192 — Skip cache span data when child span is NoOp
• #5201 — Add db.operation.name attribute to cache spans
• #5202 — Instrument putIfAbsent, replace, and getAndReplace
• #5203 — Fix cache hit detection for typed get and fix jcache docs link
• #5204 — Use method-specific span operations for cache spans
• #5205 — Merge startSpan helpers into shared core method

---

📜 Description

Instead of the 4 generic categories (cache.get, cache.put, cache.remove, cache.flush), use the actual method name as the span operation.

Applied to all Spring wrappers (spring, spring-jakarta, spring-7) and JCache wrapper. The base operations (get, put, remove) remain unchanged since the method name already matches.

Full list of renames:

Method	Before	After
retrieve()	cache.get	cache.retrieve
putIfAbsent()	cache.put	cache.putIfAbsent
replace()	cache.put	cache.replace
getAndPut()	cache.put	cache.getAndPut
getAndReplace()	cache.put	cache.getAndReplace
putAll()	cache.put	cache.putAll
evict()	cache.remove	cache.evict
evictIfPresent()	cache.remove	cache.evictIfPresent
getAndRemove()	cache.remove	cache.getAndRemove
removeAll(keys)	cache.remove	cache.removeAll
clear()	cache.flush	cache.clear
invalidate()	cache.flush	cache.invalidate
removeAll()	cache.flush	cache.removeAll
invoke()	cache.get	cache.invoke
invokeAll()	cache.get	cache.invokeAll
getAll()	cache.get	cache.getAll

Also removed the redundant first parameter from startSpan/startSpanForKeys helpers since it was always "cache." + operationName — the prefix is now derived inside the method.

💡 Motivation and Context

More granular span operations provide better visibility into which specific cache method was called, rather than grouping all operations into 4 broad categories.

💚 How did you test it?

• Updated all test assertions for span operations across all 4 modules
• All tests pass

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

#skip-changelog

[github-actions]

Semver Impact of This PR

🟢 Patch (bug fixes)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

This PR will not appear in the changelog.

---

_{🤖 This preview updates automatically when you update the PR.}

[sentry]

Sentry Build Distribution

App Name	App ID	Version	Configuration	Install Page
SDK Size	io.sentry.tests.size	8.34.1 (1)	release	Install Build

[adinauer]

@sentry review

[adinauer]

cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR