docs: add a pdd-kit Product Model, linted in CI

[itai-gendler]

Refs #1614

This adds the Product Model proposed in #1614 and the separate workflow you asked for.

The workflow

.github/workflows/product-model.yaml has one job that runs pdd-toolkit lint, pinned to 0.37.0 in one env value:

• Pull requests to main and test-*: it fails when the model is malformed or points to a file Git no longer tracks. It doesn't run on push to main.
• Weekly: it runs when CI completes, only if that was the scheduled run, and lints the commit the image was built from. I used workflow_run instead of a second cron because the scheduled CI run has started anywhere from 15:03 to 23:51 UTC over the last 12 weeks, so a fixed time could run before the build. Other CI runs show up as a skipped run of this workflow.

It needs no secrets, has read-only contents permission, and runs on ubuntu-slim in about 35 seconds.

I tested it in a private copy of the repo:

• a pull request with the model passes;
• a pull request that renames tubesync/sync/tasks.py fails, listing each model file that points to it;
• a dispatched CI run skips the weekly lint;
• with the filter widened to accept that dispatched run, the weekly lint checks out the run's commit and passes.

Why there's no catch-up job

I proposed an AI catch-up after merges, and you asked for it to check for its secret. Having thought it through, I don't think it's the right approach, so I left it out. That's also why there's no secret to check.

When the model and the code disagree, someone has to decide which one is right. Sometimes the code changed on purpose, and sometimes it's a bug the model caught. Once a change is merged, it's too late to ask. A scheduled job would either guess, and could write a bug into the model, or open a PR asking you to decide on changes you merged days ago. That's the maintenance burden you said you want to avoid.

That decision belongs in the pull request that makes the change, while its author is there:

• Contributors who use an agent can run /pdd-ideate to update the model before implementing, then /pdd-verify after implementing. They can also implement first and finish with /pdd-verify. Either way, the model change is part of the same PR and is reviewed with the code. product-model/README.md tells agents how to work with it.
• Contributors without an agent work as they do today. Lint fails only when a PR renames or removes a file the model points to. The fix is to update the path in product-model/, or a maintainer can do it. If you'd rather lint never fail for that, I can remove the code references from the model; there are 58 of them.

The weekly lint catches a broken reference that reaches main without a pull request.

🤖 Generated with Claude Code

[itai-gendler]

Closing for now. I'd like to settle the approach with you in #1614 before opening a PR.