📝 Documentation: Batching multiple commits for a single release or triggering a new release after the fact

### Documentation Report Checklist

- [x] I have pulled the latest `main` branch of the repository.
- [x] I have [searched for related issues](https://github.com/JoshuaKGoldberg/create-typescript-app/issues?q=is%3Aissue) and found none that matched my issue.

### Overview

I have scaffolded a new package using your template and got it working for the most part but noticed a few unclear steps in terms of the intended workflow and would like to know how to handle these as I haven't seen sufficient documentation on it.

1. Creating the repository also sets up GitHub in an opinionated way, specifically disabling rebases and forcing everything to be squashed. As such anything that ends up in the `main` branch will always be a single commit, be it directly to `main` or via a PR. The release workflow therefore cannot pick up multiple changes at the same time, say two features. This is particularly relevant when I'm preparing a minor or even a major version release and wouldn't want all the separate changes be summarized under a single umbrealla `feat` entry in the changelog and instead would like my users to actually see in detail what has changed. What's the recommended process to batch these changes for a single release?
2. In a similar fashion certain commits such as dependency updates don't trigger a release since they are prefixed with `chore`, especially when it's from renovate. What about the case where a critical vulnerability gets updated? This doesn't trigger a release and it seems I'd have to push an empty commit with `fix` to trigger a release which really doesn't feel right. How am I supposed with the default setup to trigger a release after performing some more relevant dependency updates?

### Additional Info

_No response_

Start by reviewing the repository's release workflow and commit conventions referenced in the report. Document how to batch multiple changes into one release and how to trigger a release for dependency or security updates; the work is done when both workflows and their expected changelog and release behavior are clear.

Written by the indexing model from the issue text.