Lint packages: project pinning by SHA and override semantics #843

Part of #616. Decisions: see the owner comments there.

Desired behavior

A project selects lint rule packages reproducibly through its existing lint configuration. Installing a package never activates it.

Scope

• A packages entry in the project lint configuration naming repo and a full commit SHA. The configuration is the lock; no second lock file.
• Rules from listed packages load through the existing lint path, with the project's severity and enablement policy applying to them. Rule files never set severity or enabled.
• A package missing from the store is fetched by its SHA, including in CI.
• Rule ID collisions between packages are errors. The first-party package is the only one that may use bare IDs; every other package must use namespace/rule-id with wright reserved. Listing the first-party repository with a SHA replaces the embedded default instead of colliding.
• Locally edited managed files are never silently overwritten.

Non-goals

The store and fetch (sibling issue), the commands, and the first-party package contents.

Acceptance criteria

• Two runs of the same project config with different packages installed globally produce the same effective rules.
• A listed package missing locally is fetched by SHA; a SHA that cannot be fetched fails with an explicit diagnostic and no lint findings.
• A duplicate effective rule ID across two packages is refused; a non-first-party package with a bare ID is refused.
• A project entry for the first-party repository replaces the embedded default without a collision.
• The accepted YAML rule syntax is unchanged.

Dependencies

The package store and fetch sub-issue.