Add structured {valid, issues} JSON contract for app config validate

[ryancbahan]

What

Change app config validate --json output from flat error strings to structured issue objects.

Why

Machine consumers (automation, repair loops, IDE integrations) need file paths, field paths, and error codes — not pre-rendered human-readable strings. This is the public contract that #7090 aimed to deliver.

How

JSON output shape changes from:

{"valid": false, "errors": ["client_id is required", "invalid type \"unknown\""]}

to:

{"valid": false, "issues": [
  {"file": "shopify.app.toml", "message": "Required", "path": ["client_id"], "code": "invalid_type"},
  {"file": "extensions/my-ext/shopify.extension.toml", "message": "invalid type \"unknown\""}
]}

• valid: true case: {valid: true, issues: []} (was errors: [])
• valid: false case: each issue has file, message, and optional path/code from Zod validation
• CLI (non-JSON) output is unchanged — still renders bullet-formatted error messages

Depends on #7126 which provides the structured ConfigurationError data that flows directly into the JSON shape.

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[ryancbahan]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add errors to TomlFile and Project for TOML parse failure tracking #7130
• Add structured {valid, issues} JSON contract for app config validate #7128 👈 (View in Graphite)
• Refactor app validation errors: result-based parsing, structured error data #7126
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.