fix(tasks) Update headings to improve sidebar (#14938)

## DESCRIBE YOUR PR
h1 headings are not included in the 'on this page' sidebar. Only h2 and
lower are included in the page contents.

## IS YOUR CHANGE URGENT?  

Help us prioritize incoming PRs by letting us know when the change needs
to go live.
- [ ] Urgent deadline (GA date, etc.): <!-- ENTER DATE HERE -->
- [ ] Other deadline: <!-- ENTER DATE HERE -->
- [x] None: Not urgent, can wait up to 1 week+

## SLA

- Teamwork makes the dream work, so please add a reviewer to your PRs.
- Please give the docs team up to 1 week to review your PR unless you've
added an urgent due date to it.
Thanks in advance for your help!

## PRE-MERGE CHECKLIST

*Make sure you've checked the following before merging your changes:*

- [ ] Checked Vercel preview for correctness, including links
- [x] PR was reviewed and approved by any necessary SMEs (subject matter
experts)
- [ ] PR was reviewed and approved by a member of the [Sentry docs
team](https://github.com/orgs/getsentry/teams/docs)

Author: markstory

develop-docs/backend/application-domains/tasks/index.mdx

@@ -8,7 +8,7 @@ asynchronously in a background worker process. The task framework within Sentry
 is inspired by [Celery](https://docs.celeryproject.org) as it was originally
 built with celery.
 
-# Defining Tasks
+## Defining Tasks
 
 Sentry tasks are configured with the `instrumented_task` decorator that
 includes features like automatic tracing and metric collection, and multi-region
@@ -213,7 +213,7 @@ def deliver_issue_webhook(organization_id: int, group_id: int) -> None:
 
 If an idempotent task exceeds a processing deadline, it will *not* be retried.
 
-# Testing Tasks
+## Testing Tasks
 
 Tasks can be tested with a few different approaches. The first is with the
 `self.tasks()` or `TaskRunner` context manager. When these context managers are
@@ -242,7 +242,7 @@ def test_schedule_task(self, mock_deliver: MagicMock) -> None:
 Mocking tasks will not validate that parameters are JSON compatible, nor will it catch TypeErrors from signature mismatches.
 </Alert>
 
-# Task namespaces
+## Task namespaces
 
 Task namespaces are created as code, and configuration are linked to the
 namespace when it is declared.
@@ -269,7 +269,7 @@ will be run in our `default` worker pools. If your task namespace will be
 high-throughput (more than 1500 tasks per second) consider provisioning
 a dedicated pool for your tasks.
 
-# Periodically Scheduled Tasks
+## Periodically Scheduled Tasks
 
 Task can also be set to spawn on a periodic schedule. To accomplish this, simply
 update the `TASKWORKER_SCHEDULE` configuration found in

develop-docs/backend/application-domains/tasks/terminology-and-concepts.mdx

@@ -28,7 +28,7 @@ deliver_issue_webhook.delay(organization_id=org.id, issue_id=issue.id)
 See [Defining Tasks](/backend/application-domains/tasks/#defining-tasks) for
 more information on defining tasks.
 
-# Task Namespaces
+## Task Namespaces
 
 Namespaces provide logical groupings of tasks by product domain or
 functionality. All task activations within a namespace are processed in order
@@ -79,7 +79,7 @@ namespace:ingest.profiling --> kr[kafka-replays]
 
 ```
 
-# System Components
+## System Components
 
 The task framework is composed of a few components:
 
@@ -95,7 +95,7 @@ w -- publish result --> b
 
 Client applications produce TaskActivation messages (serialized as protobuf messages) to Kafka topics. Taskbroker instances consume Kafka messages, and make activations available to workers via gRPC.
 
-# Terminology
+## Terminology
 
 - `Task` A function that can be scheduled to run later. Tasks are executed by workers, and can be retried should they fail.
 - `TaskNamespace` A collection of related tasks that are operated together. Activations within a namespace will be ordered, but activations between namespaces have no ordering promises.