refactor: extract inline linters to standalone scripts and automate local checks

# RFC: Onboard Standalone Linter Scripts & Local Developer Workflows (pre-commit, jj fix, IDE)

## 1. The Problem & Motivation

Currently, the repository's CI-coupled linters (specifically for **Shell** and **YAML**) are written as inline bash scripts nested inside GitHub Actions composite actions (e.g., `.github/actions/lint-shell/action.yml` and `lint-yaml/action.yml`).

Because these linter runs are coupled to the CI runner environments (and download their own binaries during execution), developers cannot easily run them locally. This introduces a **feedback lag**: developers only discover minor linting, formatting, or action-pinning (Ratchet) errors *after* pushing a commit and waiting for the CI run to complete on a Pull Request.

## 2. Proposed Solution (The Refactoring)

To bridge the gap between local development and CI, we propose a refactor that establishes a **single source of truth** for all repository checks while onboarding developers to automated local workflows.

An end-to-end prototype of this implementation has been staged on branch [local-linter-onboarding](https://github.com/Capstan/actions/tree/local-linter-onboarding).

### Key Pillars of the Refactor:

#### A. Standalone Linter Scripts (Single Source of Truth)
We have extracted the inline linter executions into standalone shell scripts under a new `scripts/` directory:
* `scripts/lint-shell.sh` (runs `shellcheck` with file/directory expansion and CI/local output modes).
* `scripts/lint-yaml.sh` (runs `yamllint` respecting local configurations or falling back to default configs).
* The composite actions (`lint-shell` and `lint-yaml`) have been updated to execute these standalone scripts. This guarantees the scripts serve as the actual CI engine, while making them immediately runnable by developers.

#### B. Git Hook Automation (`pre-commit` integration)
We have onboarded the `pre-commit` framework by adding a `.pre-commit-config.yaml` file at the repository root. It automatically hooks our standalone local scripts to run on staged files during `git commit`:
* **Lint Shell:** Runs `scripts/lint-shell.sh`.
* **Lint YAML:** Runs `scripts/lint-yaml.sh`.
* **Check Ratchet:** Runs our custom `.github/actions/lint-github-actions/check_ratchet.sh` to prevent developers from accidentally committing unpinned GitHub Actions.

#### C. Jujutsu Native Integration (`jj fix`)
For developers utilizing Jujutsu (`jj`), we have documented how to natively hook these scripts into `jj fix` via `.jj/config.toml` patterns, allowing on-demand formatting/checking.

#### D. Real-time IDE Integration (VS Code)
A `.vscode/extensions.json` and `.vscode/settings.json` file have been added. When opening this repository, developers will be automatically prompted to install the corresponding extensions (**ShellCheck**, **YAML**, **YamlLint**) configured to read the local `.yamllint.yml` and highlight errors inline *as they type*.

---

## 3. Implementation Details & Documentation

A **`DEVELOPMENT.md`** has been added to the repository. It provides instructions for developers to:

1. Run the standalone scripts manually.
2. Set up and install `pre-commit` system-wide (with `apt`, `brew`, or `pipx`).
3. Configure their `.jj` settings for `jj fix`.
4. Initialize their VS Code workspaces for instant feedback.

---

## 4. Request for Feedback

This refactor improves developer velocity and code quality by shifting linting checks left.

* **Example Branch:** The staged implementation can be reviewed on branch [local-linter-onboarding](https://github.com/Capstan/actions/tree/local-linter-onboarding).
* **Questions for the team:**
1. Is this local workflow onboarding valuable?
2. If so, is it worth standardizing across other `abcxyz` repos?
3. Are there any other linters (e.g., Go, Terraform) we should scriptize and onboard next?

Please let us know your thoughts!