Add settings to auto-apply linting, fix linting errors

[ryanahamilton]

Follow-up to #57455

When attempting to back-port #57455 into v3-1-test, merging was blocked by linting errors that were not shown by my IDE when authoring, nor did they become blocking when attempting to commit the code.

@bbovenzi is going to investigate why I was able to commit the invalid code, and in this PR, I am fixing the previously uncaught issues.

I added .vscode/ config files that ensure auto-formatting occurs on-save for UI files. After I configured this, it resolved most of the issues automatically. These setting work for VS Code or any fork of it (like Cursor).

Most of the issues were related to prop ordering and indentations, but it did catch an issue in how the Plugin nav item icons are being rendered and I've fixed that as well.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 968b637 v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[rawwar]

I don't think we should have .vscode in the repo. I have my own vscode config and now, it always shows up as a change.

If required, we can update setup_vscode.py to automatically generate such config. we already use that to generate debug config

[ryanahamilton]

I don't think we should have .vscode in the repo. I have my own vscode config and now, it always shows up as a change.

If required, we can update setup_vscode.py to automatically generate such config. we already use that to generate debug config

In other projects I've worked on we check these files in as the "Workspace" configuration as they are considered to have a collective agreement around them. In the case of the settings I added, those enforce the required linting of the project and should not be optional.