chore: run precommit on all files

docs/concurrentRevisionHandling.md

@@ -16,12 +16,13 @@ An Amendment is opened on a project, and left open while it is being negotiated.
 A solution that would allow us to handle concurrency without user input on conflict resolution was needed. To achieve this, the approach taken is comparable to a git rebase. When committing and pending are in conflict, the changes made in pending are applied on top of the committing form change, as if the committing `form_change` were the original parent of the pending `form_change`. While users commit on a `project_revision` level, the change propogates down to the `form_change` level, so when we're talking about this here it is at the `form_change` granularity, and the heart it takes place in the function `cif.commit_form_change_internal`.
 
 One of the ways our various forms can be categorized would be:
+
 - forms a project can have at most one of (`funding_parameter_EP`, `funding_parameter_IA`, `emission_intensity`, `project_summary_report`)
 - 'project_contact' are either primary or secondary, and have a `contactIndex`
 - 'project_manager' are categorized by `projectManagerLabelId`
 - 'reporting_requirement' have a `reportingRequirementIndex` based on the `json_schema_name`
 
-Form changes can have an operation of `create`, `update`, or `archive`, each of which need to be handled for all of the above categories. This results in several unique cases, which have been explained case-by-case using in-line in the `commit_form_change_internal` where they have more context. 
+Form changes can have an operation of `create`, `update`, or `archive`, each of which need to be handled for all of the above categories. This results in several unique cases, which have been explained case-by-case using in-line in the `commit_form_change_internal` where they have more context.
 
 After each of the following cases, the `previous_form_change_id` of the pending `form_change` is set to be the id of the committing `form_change`, which leaves every form change with a `previous_form_change_id` of the **last commit** corresponding `form_change`, while preserving the option of a full history by maintaining accurate `created_at`, `updated_at`, and `archived_at` values for all `form_change`.
 

schema/deploy/mutations/commit_form_change_internal.sql

@@ -134,7 +134,7 @@ begin
           project_revision_id => pending_project_revision_id,
           json_schema_name => fc.json_schema_name,
           new_form_data => (fc.new_form_data || format('{"reportingRequirementIndex": %s}',
-            (select max((new_form_data ->> 'reportingRequirementIndex')::int) from cif.form_change 
+            (select max((new_form_data ->> 'reportingRequirementIndex')::int) from cif.form_change
               where project_revision_id=pending_project_revision_id
               and json_schema_name = fc.json_schema_name
               and new_form_data ->> 'reportType' = fc.new_form_data ->> 'reportType'
@@ -163,7 +163,7 @@ begin
           project_revision_id => pending_project_revision_id,
           json_schema_name => fc.json_schema_name,
           new_form_data => (fc.new_form_data || format('{"reportingRequirementIndex": %s}',
-            (select max((new_form_data ->> 'reportingRequirementIndex')::int) from cif.form_change 
+            (select max((new_form_data ->> 'reportingRequirementIndex')::int) from cif.form_change
               where project_revision_id=pending_project_revision_id
               and json_schema_name = fc.json_schema_name
             ) + 1)::jsonb