Run pre-commit run --all and save the results

dandiapi/api/templates/api/mail/dandiset_unembargo_failed.html

@@ -4,4 +4,4 @@
 dandiset in the meantime, as that may hinder or delay the process of resolving this issue.
 If in two business days your dandiset is still embargoed, please reply to this email.
 <br><br><br>
-<em>You are receiving this email because you are an owner of this dandiset.</em>
+<em>You are receiving this email because you are an owner of this dandiset.</em>

doc/design/audit-trail-mvp.md

@@ -32,14 +32,14 @@ at https://github.com/dandisets.
 
    A possible example of such a display follows (the final rendered form may
    differ from this depending on best practices, etc.):
-    
+
     ```
     YYYYMMDDTHHMMSS.mmmm: X added asset at path (/full/path) checksum
     YYYYMMDDTHHMMSS.mmmm: X updated asset at path (/full/path) checksum
     YYYYMMDDTHHMMSS.mmmm: X removed asset at path (/full/path) checksum
     YYYYMMDDTHHMMSS.mmmm: X updated dandiset metadata
     ```
-    
+
 3. **Extensible significant action list.** The significant actions the system is
    capable of tracking should be extensible--that is, in the future new actions
    should be able to be added to the system, and existing actions should be able

doc/design/deployment-1.md

@@ -7,7 +7,7 @@ The staging Netlify site is deployed automatically from `master`. The production
 
 The staging and production Heroku apps are deployed manually from a GitHub CI workflow using a GitHub action.
 
-Netlify and Heroku can deploy themselves automatically from a branch, but not from a release tag. This means we need to deploy manually from GitHub CI, which is quite complex and not ideal. Additionally, Netlify does not support multiple `netlify.toml` configuration files in a single project directory, which means the deployment CI step deletes the `netlify.toml` in the production deployment and specifies the environment with the Netlify CLI instead. 
+Netlify and Heroku can deploy themselves automatically from a branch, but not from a release tag. This means we need to deploy manually from GitHub CI, which is quite complex and not ideal. Additionally, Netlify does not support multiple `netlify.toml` configuration files in a single project directory, which means the deployment CI step deletes the `netlify.toml` in the production deployment and specifies the environment with the Netlify CLI instead.
 
 This proposed solution is to use a second `release` branch which tracks the released code. This allows us to use the automatic Netlify and Heroku deployments rather than pushing manually from GitHub CI.
 

doc/design/embargo-full.md

@@ -85,4 +85,4 @@ If this becomes an issue, we could:
 - email the owners of an embargoed dandiset (and admins) when it has been successfully unembargoed
 - on the stats page, display the full amount of data stored in the archive, and indicate how much of it is under embargo
   - e.g., `300 TB total data size (100 TB currently under embargo)`
-  - link the word "embargo" to docs/explanation thereof
+  - link the word "embargo" to docs/explanation thereof

doc/design/garbage-collection-1.md

@@ -58,4 +58,4 @@ The actual implementation of these operations should be added to `dandiapi.api.g
 
 After thoroughly testing the script by hand in staging/production, a Celery Beat task should be created that checks for stale data nightly.
 
-All of these numbers should be available in the admin data dashboard so that we can independently verify that the scheduled task is working correctly.
+All of these numbers should be available in the admin data dashboard so that we can independently verify that the scheduled task is working correctly.