Auto-generate typed config fields from product documentation

Summary

The operator now has a passthrough mechanism (#75) for arbitrary config values, but still only covers ~25-33% of each product's typed config fields. We should auto-generate these typed fields from the product documentation rather than maintaining them by hand.

Context

• Connect has ~200+ config values, operator defines ~65
• Package Manager has ~100+ config values, operator defines ~25
• Both use gcfg format with well-structured documentation at docs.posit.co
• The documentation HTML is consistently formatted and parseable (Section.Key headings with Type/Default metadata)
• Workbench is deferred — multiple config files, scattered docs, passthrough-only for now

Work

• Write a scraper/parser for the Connect and Package Manager configuration reference pages
• Generate Go structs with appropriate types, json tags, kubebuilder validation markers, and doc comments
• Define type mapping: doc types (string, boolean, integer, duration, byte-size, etc.) → Go types
• Handle enums via kubebuilder validation markers
• Output to connect_config_generated.go and package_manager_config_generated.go
• Add CI job to detect drift between generated code and latest product docs
• Determine whether generation runs at build-time or as a periodic sync workflow
• Consider version tagging: generated code should record which product version it was generated from
• Consider how dev/pre-release product versions interact with generated configs (passthrough covers the gap)

References

• Passthrough PR: #75
• Connect config docs: https://docs.posit.co/connect/admin/appendix/configuration/
• Package Manager config docs: https://docs.posit.co/rspm/admin/appendix/configuration/

Start with the Connect and Package Manager configuration reference pages and the passthrough work in PR #75. Design the scraper, type mapping, generated outputs connect_config_generated.go and package_manager_config_generated.go, and drift check around the documented HTML structure. Done means typed structs, validation markers, comments, version handling, and an agreed build-time or periodic generation workflow.