docs: fix broken anchors and stale HarperDB org URLs

Two broken anchors surfaced by the build's anchor check:

- reference/backups/overview.md linked to a nonexistent
  ../cli/commands.md#backing-up-with-volume-snapshots. Repointed at
  #how-backups-work, the existing heading whose section covers the
  volume-snapshot approach for LMDB databases.
- release-notes/v5-lincoln/5.1.md used a same-page #deployment-operations
  anchor for a target that lives in the Operations API reference.
  Repointed at /reference/v5/operations-api/operations#deployment-operations.

The GitHub org was renamed HarperDB -> HarperFast. Old URLs still resolve
via redirect, but the canonical targets are now used directly. Every
HarperFast/* target was verified to exist. npm package names
(@harperdb/status-check, @harperdb/prometheus-exporter,
@harperdb/acl-connect, @harperdb/nextjs) are unchanged - those scopes are
the canonically published names and only the github.com links moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: Ethan-Arrowood

reference/backups/overview.md

@@ -32,7 +32,7 @@ The offline path matters for restore. RocksDB is single-writer, so an in-place r
 
 ## Limitations
 
-- **Managed backups require the RocksDB storage engine.** For LMDB databases, use [`get_backup`](./operations.md#get_backup) or [volume snapshots](../cli/commands.md#backing-up-with-volume-snapshots).
+- **Managed backups require the RocksDB storage engine.** For LMDB databases, use [`get_backup`](./operations.md#get_backup) or [volume snapshots](../cli/commands.md#how-backups-work).
 - **Whole-database granularity.** There is no per-table backup or restore. (The one exception: `get_backup` on an LMDB database can stream individual tables, and includes the audit store only with `include_audit`.)
 - **One storage root per database.** A database whose tables use per-table `path` storage configs spans multiple root stores and cannot be backed up with these operations.
 - **Backups live on the node that created them.** The backup repository is a local directory. RocksDB shares files across backup IDs (a backup ID is not a self-contained folder), so disaster-recovery copies must take the entire per-database repository — `<backupPath>/<database>` — not an individual backup, and must do so while no backup operation is running, or from an atomic filesystem snapshot. A live recursive copy can race `create_backup`/`delete_backup`/`purge_backups` and produce an unrestorable copy. Alternatively, use `get_backup` to pull a snapshot from a running server.

reference/components/applications.md

@@ -122,14 +122,14 @@ When deploying remotely, the `package` field can be any valid npm dependency val
 
 - **Omit** `package` to package and deploy the current local directory
 - **npm package**: `package="@harperdb/status-check"`
-- **GitHub**: `package="HarperDB/status-check"` or `package="https://github.com/HarperDB/status-check"`
+- **GitHub**: `package="HarperFast/status-check"` or `package="https://github.com/HarperFast/status-check"`
 - **Private repo (SSH)**: `package="git+ssh://git@github.com:HarperDB/secret-app.git"`
 - **Tarball**: `package="https://example.com/application.tar.gz"`
 
 When using git tags, use the `semver` directive for reliable versioning:
 
 ```
-HarperDB/application-template#semver:v1.0.0
+HarperFast/application-template#semver:v1.0.0
 ```
 
 Harper generates a `package.json` from component configurations and uses a form of `npm install` to resolve them. This is why specifying a local file path creates a symlink (changes are picked up between restarts without redeploying).
@@ -337,7 +337,7 @@ Deploys a component using a package reference or a base64-encoded `.tar` payload
 {
 	"operation": "deploy_component",
 	"project": "my-component",
-	"package": "HarperDB/application-template#semver:v1.0.0",
+	"package": "HarperFast/application-template#semver:v1.0.0",
 	"replicated": true,
 	"restart": "rolling"
 }

reference/fastify-routes/overview.md

@@ -12,7 +12,7 @@ Fastify routes are discouraged in favor of modern routing with [Custom Resources
 
 Harper provides a build-in plugin for loading [Fastify](https://www.fastify.io/) routes as a way to define custom endpoints for your Harper application. While we generally recommend building your endpoints/APIs with Harper's [REST interface](../rest/overview.md) for better performance and standards compliance, Fastify routes can provide an extensive API for highly customized path handling. Below is a very simple example of a route declaration.
 
-The fastify route handler can be configured in your application's config.yaml (this is the default config if you used the [application template](https://github.com/HarperDB/application-template)):
+The fastify route handler can be configured in your application's config.yaml (this is the default config if you used the [application template](https://github.com/HarperFast/application-template)):
 
 ```yaml
 fastifyRoutes:

release-notes/v5-lincoln/5.1.md

@@ -157,7 +157,7 @@ New operations provide access to deployment history:
 - `get_deployment_payload` — retrieve the stored tarball for a deployment
 - `delete_deployment_payload` — free storage by removing the payload blob after deployment
 
-See [Deployment Operations](#deployment-operations) in the Operations API reference for details.
+See [Deployment Operations](/reference/v5/operations-api/operations#deployment-operations) in the Operations API reference for details.
 
 ## HNSW int8 Quantization