docs(migrations): Update is_dangerous -> is_post_deployment

src/docs/database-migrations.mdx

@@ -123,7 +123,7 @@ generally prefer that, since it averages the load out over a longer period of ti
 We prefer to create indexes on large existing tables with `CREATE INDEX CONCURRENTLY`. Our migration framework will do this automatically when creating
 a new index. Note that when `CONCURRENTLY` is used we can't run the migration in a transaction, so it's important to use `atomic = False` to run these.
 
-When adding indexes to large tables you should use a `is_dangerous` migration as creating the index could take longer than the migration statement timeout of 5s.
+When adding indexes to large tables you should use a `is_post_deployment` migration as creating the index could take longer than the migration statement timeout of 5s.
 
 ### Deleting columns
 
@@ -433,7 +433,7 @@ Deployment migrations are run in each region and tenant before code is deployed.
 * Removing columns and tables - as long as you follow the processes outlined
   above.
 
-### Post-deploy migrations (is_dangerous) 
+### Post-deploy migrations (`is_post_deployment`) 
 
 Post-deploy migrations are run manually by engineers **after** a migration has been deployed **to all** regions. During deployment, post-deploy migrations are marked as complete (faked) with django's fake migration behavior. When a post-deploy migration is run, it is run against all regions and tenants. Post-deploy migrations are triggered manually by engineers.
 
@@ -468,6 +468,8 @@ Then click `Environment Variables` and fill in a value for `django_app` and `dja
 
 ![post-deploy migration variables](/post-deploy-pipeline-variables.png)
 
+Finally, click the `Trigger Pipeline` button.
+
 ### Cancelling a post-deploy migration
 
 Just cancel the GoCD stage.