chore(repo): stabilize CI and align workflow with protected main

[bochkov-anton]

Before you submit

Use this template to explain the change clearly to maintainers and reviewers.

Summary

• Redesigns sync.Pool-sensitive tests so they validate the actual package and backend contracts instead of assuming deterministic immediate round-trip reuse.
• Refines lint policy and benchmark/test source layout so intentional benchmark patterns remain valid while the repository still passes the current lint baseline.
• Improves repository automation by broadening fast quality checks, tightening PR-only dependency/commit validation, making benchmark-smoke artifact upload non-masking, and gating stable release / attestation flows on SemVer tags reachable from main.
• Simplifies the branch model for this small library: the repository now documents and enforces a protected-main, topic-branch workflow instead of a permanent next -> main promotion flow.
• Aligns contributor-facing documentation and metadata with the new workflow, including CONTRIBUTING.md, the PR template, Dependabot targeting, and release-policy comments.

Linked work

• Issue(s): None
• Design / proposal: None
• Report / benchmark reference: None
• Auto-close directive (Closes #123, Fixes #123, etc.): None

Change classification

Select all items that apply.

• Bug fix
• Feature
• Refactoring with no intended behavior change
• Performance or allocation improvement
• Benchmark / chart / report tooling change
• Documentation change
• Build / CI / release tooling change
• Security / ownership / isolation clarification
• Breaking change
• Mechanical change only

Affected areas

Select all repository areas materially affected by this PR.

• Public runtime (Pool[T], Get, Put)
• Lifecycle policy (Options[T], Reset, Reuse, OnDrop)
• Backend (internal/backend)
• Ownership / concurrency contract
• Public package docs / Go doc
• Unit tests
• Benchmark source files
• Benchmark scripts (bench/scripts)
• Charts / reports / performance docs
• Root README or repository docs
• CI / release / repository automation

Why this change

What problem existed before this PR?
Why is this change needed now?

• Problem statement:
  • Several tests encoded invalid sync.Pool assumptions, especially “the next Get must return the same instance/value that was just Put”.
  • The lint layer mixed real signal with benchmark-specific patterns and a few stale suppressions / formatting issues.
  • Benchmark smoke could fail twice by masking the real failure with a secondary missing-artifact upload error.
  • The repository workflow had grown into a next -> main -> tag model that is heavier than needed for a small Go library.
  • Contributor docs, PR metadata, Dependabot targeting, and workflow triggers no longer matched the desired protected-main model cleanly.
• Why now:
  • CI was red on correctness and lint issues.
  • The repository is already publication-oriented, so the branch model, release guards, and contributor guidance need to be unambiguous before further releases.
• Who benefits (caller, maintainer, contributor, benchmark/report workflow, etc.):
  • Maintainers get a simpler protected-branch model and clearer release / attestation boundaries.
  • Contributors get clearer PR flow, branch naming, commit-title expectations, and local validation guidance.
  • CI gets more reliable contract tests and less noisy workflow behavior.
  • Benchmark/report tooling gets smoke validation that fails for the real cause instead of artifact-upload noise.

Reviewer guidance

Tell reviewers where to focus.

• Review focus:
  • sync.Pool contract corrections in tests and backend helper boundaries.
  • Workflow trigger policy and stable release / attestation gating.
  • main-only contributor flow in docs and metadata.
• Key invariants or contracts:
  • The package must not claim deterministic same-instance reuse from raw sync.Pool.
  • Stable releases and attestations must only come from SemVer tags that point to commits reachable from main.
  • Fast quality checks should run broadly on working branches, while release-only workflows must stay tag-gated.
  • The repository no longer treats next as part of the normal contribution or release flow.
• Files / flows worth focused review:
  • pool_test.go
  • internal/backend/syncpool.go
  • internal/backend/syncpool_test.go
  • .golangci.yml
  • .github/workflows/*.yml
  • CONTRIBUTING.md
  • .github/PULL_REQUEST_TEMPLATE.md
  • .github/dependabot.yml
• Explicitly out of scope:
  • Public API expansion
  • New benchmark families or new report methodology
  • Release-candidate / prerelease publishing
  • Deleting any remote branch from inside the repository

Behavioral and contract impact

Describe what changes in package behavior, documentation, or repository workflow.

If a section does not apply, write None.

• Public API impact:
  • None. No new exported API was added and no existing exported API contract was intentionally widened.
• Lifecycle semantic impact:
  • No intended runtime semantic change. The main change is that tests and docs now describe and validate the real contract instead of an unsupported immediate round-trip identity guarantee.
• Ownership or concurrency impact:
  • Ownership / reuse guidance is clearer because tests now focus on accepted vs rejected paths, reset/drop ordering, and realistic reuse boundaries.
• Backend or storage impact:
  • Added a small typed-assertion helper in the backend so impossible wrong-type paths can be tested deterministically without relying on nondeterministic raw sync.Pool behavior.
• Benchmark or report workflow impact:
  • Benchmark smoke remains lightweight, validates representative benchmark families and chart generation, and no longer turns missing artifacts into a secondary masking failure.
  • Benchmark/test source files were updated to current lint/style expectations without changing the intent of pointer-vs-value contrast benchmarks.
• Documentation or example impact:
  • Contributor docs, PR guidance, Dependabot policy, and branch-protection guidance now describe a protected-main, topic-branch workflow.
• Failure mode / misuse sensitivity:
  • Stable release / attestation workflows now reject tags that are not reachable from main.
  • No new runtime misuse surface was introduced.

Validation

Prefer copy-pasteable commands and precise evidence.

Validation steps

1. Reworked the failing correctness tests so they validate supported sync.Pool-backed behavior.
2. Fixed the targeted lint failures in benchmark/test files and verified formatting / vet.
3. Revalidated automation and contributor-flow changes locally, then confirmed GitHub Actions checks are green.

Validation evidence

• Commands / suites:
  • go test ./...
  • go test -race ./...
  • go vet ./...
  • python3 scripts/check_docs_smoke.py --repo-root . --summary-path /tmp/pool-docs-smoke-summary.md
  • node --check release.config.cjs
  • node --check commitlint.config.cjs
  • Ruby YAML parse for .github/workflows/*.yml and .github/*.yml
  • git diff --check
• Environment:
  • Local repository checkout on the current branch plus GitHub Actions validation
• Evidence summary:
  • Local unit, race, and vet checks passed.
  • Docs smoke passed.
  • Workflow/config syntax checks passed.
  • All GitHub Actions checks are green for the current branch/PR state.
• Remaining validation gaps:
  • None for the intended scope of this PR.

Tests executed

Select what actually ran for this PR.

• Unit tests
• Race detector
• Backend tests
• Benchmark compilation / smoke validation
• Benchmarks / benchmark scripts
• Chart generation validation
• Documentation validation
• Lint / static analysis
• Manual validation
• Not run, explained above

Performance evidence

Complete this section if the PR makes any performance, allocation, or chart/report claim.
If not applicable, write None.

None.

• Relevant benchmark family: None
• Raw artifact(s): None
• Compare artifact(s): None
• Chart or report reference: None
• Claim being made: None
• Limits of that evidence: None

Compatibility and release impact

Be explicit even when there is no impact.

• Breaking change: [x] No [ ] Yes
• Migration required: [x] No [ ] Yes
• Public API changed: [x] No [ ] Yes
• Lifecycle / ownership semantics changed: [x] No [ ] Yes
• Benchmark methodology or chart/report expectations changed: [x] No [ ] Yes
• Default behavior changed: [ ] No [x] Yes

Migration or upgrade notes

What should maintainers or users do when adopting this change?

• Maintainers should keep main as the protected default branch and stop treating next as part of the normal contribution/release flow.
• If a remote next branch still exists, it should be treated as obsolete and may be deleted manually only after confirming that it contains no unique changes.
• Stable tags and stable releases should be created only from commits reachable from main.
• Dependabot and normal PR flow should target main.

Security and data-safety considerations

For this package, security-relevant changes may include:

• object reuse causing stale data retention;
• ownership confusion after Put;
• concurrency misuse surfaces;
• documentation that could cause unsafe caller assumptions.

If not applicable, write None.

• Security / ownership / data-retention impact:
  • No new runtime security surface was introduced. The change reduces the risk of misleading lifecycle / reuse assumptions by aligning tests and contributor guidance with the actual contract.
• New trust assumptions or misuse risks:
  • None added. Release and attestation policy is stricter because stable artifacts must now come from tags reachable from main.
• Third-party material copied or adapted:
  • None.
• License / attribution follow-up:
  • None.

Known limitations and follow-up

• Known limitations:
  • This PR intentionally does not add a prerelease / release-candidate branch model.
  • If future release stabilization needs become more complex, maintainers may still choose an exceptional temporary release/vX.Y.Z branch.
• Follow-up work:
  • Optional GitHub-side follow-up: confirm branch protection, required checks, default branch, and release-environment settings match the documented main-only model.

Author checklist

Select all items that are true for this PR.

• I reviewed the diff myself before requesting review.
• I removed accidental secrets, tokens, personal data, debug-only artifacts, and temporary benchmark outputs.
• I added or updated tests where needed, or explained why they were not run.
• I updated documentation, examples, or comments where needed.
• I described lifecycle, ownership, compatibility, and behavioral impact where relevant.
• I attached benchmark/report evidence for any performance claim.
• I reviewed benchmark, chart, or report implications where relevant.
• CI is green, or failing / non-required jobs are explained.