chore: prepare v1.52.2 release

[erraggy]

Summary

• Pre-release preparation for v1.52.2
• Includes CI benchmark results

Checklist

• All tests pass
• Benchmarks recorded
• Documentation reviewed

---

🤖 Generated by prepare-release.sh

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR performs a release preparation update, bumping the plugin version from 1.52.1 to 1.52.2 in the manifest configuration files and adding benchmark results for the new release.

Changes

Cohort / File(s)	Summary
Version Manifest Updates .claude-plugin/marketplace.json, plugin/.claude-plugin/plugin.json	Updated version field from 1.52.1 to 1.52.2 in both plugin manifest files.
Benchmark Results benchmarks/benchmark-v1.52.2.txt	Added new benchmark data file containing go test/benchmark output results for multiple packages including parser, validator, fixer, converter, and related components with performance metrics (ns/op, allocations, iterations).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• oastools#345: Updates plugin version in manifest files and adds corresponding benchmark file for sequential releases.
• oastools#336: Performs identical version bump pattern across the same manifest files with accompanying benchmark results file.
• oastools#339: Modifies the same plugin manifest files and adds benchmark result files in parallel release cycle.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'chore: prepare v1.52.2 release' clearly and concisely summarizes the main change - preparing a release for version 1.52.2, which matches the changeset content.
Description check	✅ Passed	The description is directly related to the changeset, mentioning pre-release preparation for v1.52.2 and CI benchmark results, which aligns with the actual changes made.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/v1.52.2-release-prep

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.78%. Comparing base (cfe923c) to head (f8f0bab).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #347   +/-   ##
=======================================
  Coverage   84.78%   84.78%           
=======================================
  Files         193      193           
  Lines       27255    27255           
=======================================
  Hits        23108    23108           
  Misses       2828     2828           
  Partials     1319     1319           

🚀 New features to boost your workflow:

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@benchmarks/benchmark-v1.52.2.txt`:
- Around line 93-100: Benchmarks show WithPool variants for ParameterSlice,
ServerSlice, StringSlice, and DeepCopyWork are slower with identical allocation
stats, so locate the pool usage for those types (any constructors/factory
functions or methods that reference ParameterSlice, ServerSlice, StringSlice,
DeepCopyWork and their pools) and either remove/disable pooling on hot paths or
raise the reuse threshold/size to avoid synchronization overhead; specifically
update the allocation site(s) that fetch from the pool to fall back to direct
allocation (or use a less-contended pooling strategy) and run the benchmarks
again (compare against BenchmarkMarshalBufferPool which demonstrates effective
pooling) to confirm the change improves latency.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Pool implementations show overhead exceeding benefit for several slice types.

For ParameterSlice, ServerSlice, StringSlice, and DeepCopyWork, the WithPool variants are measurably slower than WithoutPool while reporting identical B/op and allocs/op. This indicates pool synchronization cost is not being offset by allocation savings for these smaller/faster types — contrast with BenchmarkMarshalBufferPool (lines 90–91) where the pool correctly reduces a 1449 ns/4144 B allocation to ~21 ns/0 B.

If these pool paths are on hot request threads, consider whether the pool is worth keeping for those specific types, or whether the pool threshold needs to be raised.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@benchmarks/benchmark-v1.52.2.txt` around lines 93 - 100, Benchmarks show
WithPool variants for ParameterSlice, ServerSlice, StringSlice, and DeepCopyWork
are slower with identical allocation stats, so locate the pool usage for those
types (any constructors/factory functions or methods that reference
ParameterSlice, ServerSlice, StringSlice, DeepCopyWork and their pools) and
either remove/disable pooling on hot paths or raise the reuse threshold/size to
avoid synchronization overhead; specifically update the allocation site(s) that
fetch from the pool to fall back to direct allocation (or use a less-contended
pooling strategy) and run the benchmarks again (compare against
BenchmarkMarshalBufferPool which demonstrates effective pooling) to confirm the
change improves latency.