Add daily workflow to refresh generated developer docs

[antiguru]

Summary

• Adds a GitHub Actions workflow that runs .claude/commands/update-docs.md daily at 06:00 UTC via claude-code-action
• Creates an auto-merge PR with updates to doc/developer/generated/
• Write scope enforced at two levels: restricted Claude tools + scoped git add

Test plan

• Trigger manually via workflow_dispatch and verify it creates a PR with only doc/developer/generated/ changes
• Verify auto-merge engages after PR checks pass

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[def-]

Do we really want to have this live in the Materialize repo? What about reviewing the generated developer docs? I'm worried it might degenerate and we wouldn't even notice.

[bosconi]

I think it makes sense to have this run daily - for these docs to be useful they have to be up to date.

Automerge is a bit of an experiment. But let's do the experiment and take stock after a month? (I have put a reminder on my calendar.)

One thing that might help reduce drift is adding instructions to update-docs.md to make minimizing edits a first-order objective, along side updating the text to reflect the code file changes. Claude came up with this as a human and LLM-friendly expression of this idea:

## Editing Existing Documentation

Make surgical edits. Only change text that is:
  - Factually incorrect
  - Grammatically broken
  - Directly related to the task you were given

Do not rephrase, reword, or restructure text that is already correct.
Treat existing wording as intentional. If a sentence is awkward but
accurate, leave it alone unless you were specifically asked to improve it.

When updating docs to reflect a code change, touch only the sentences
that the change invalidates. Everything else stays verbatim.

(And it offered this as a rewording/formatting of the existing section on style:

## Documentation Writing Style

Describe the code's current state, not what changed.

Write as if the reader is seeing the codebase for the first time.
They have no knowledge of prior implementations, so references to
what something "used to be" are meaningless to them.

Avoid changelog language:
  - "now", "added", "new"
  - "no longer", "has been removed"
  - "previously", "was replaced"
  - "changed from", "updated to", "instead of"

Examples:
  Good: "MZ_DATABASES is a BuiltinMaterializedView backed by a query over the catalog."
  Bad:  "MZ_DATABASES is now a BuiltinMaterializedView (rather than a BuiltinTable)."

The "bad" example fails twice: "now" implies a change, and the parenthetical
references an implementation the reader never saw.

)

[antiguru]

I think the automerge should only fire after someone approves the PR, unless the user generating the PR is in the exception list. Easy to change, but my intention was that we have a human in the loop for a while. And, we should check that it behaves as intended.

[bosconi]

Looks good. Let's see how much drift we get!

[antiguru]

Incorporated the feedback; please check 0192ec8 for details.

[bosconi]

Even better. Thank you!