Implement declarative GitHub repository settings management

## Vision

Create a GitHub Actions-based system to manage ALL repository settings declaratively from source control, enabling full repository reconstruction and configuration-as-code.

## Problem Statement

Currently, repository settings like description, visibility, topics, and other configurations are managed manually through the GitHub UI or API. This violates the infrastructure-as-code principle and makes it impossible to:
- Track setting changes in git history
- Reproduce repository configuration
- Apply the "spilled coffee principle" to repository settings

## Proposed Solution

### 1. Repository Settings Configuration File
Create `.github/repository-settings.yml` (or similar) containing all configurable settings:

```yaml
# .github/repository-settings.yml
repository:
description: "AI-orchestration dotfiles. Manage multiple agents in parallel for 100x developer throughput. Self-healing, principle-driven, built for the AI era."
homepage: ""
private: false
has_issues: true
has_projects: true
has_wiki: false
has_pages: false
has_discussions: false
default_branch: main
topics:
- dotfiles
- mcp
- ai-orchestration
- developer-experience
- bash
- configuration

# Security settings
security:
automated_security_fixes: true
vulnerability_alerts: true

# Branch protection rules
branch_protection:
main:
required_reviews: 1
dismiss_stale_reviews: true
require_code_owner_reviews: false
required_status_checks:
strict: true
contexts: []
```

### 2. GitHub Action for Synchronization
Create `.github/workflows/sync-repository-settings.yml`:
- Triggers on push to main when settings file changes
- Reads configuration from YAML
- Uses GitHub API to update repository settings
- Validates settings before applying
- Reports any failures

### 3. Additional Considerations

- **Secrets handling**: Some settings might require elevated permissions
- **Validation**: Ensure settings are valid before applying
- **Rollback**: Track previous settings for potential rollback
- **Audit trail**: Log all changes made by the action

## Benefits

1. **Version Control**: All settings tracked in git history
2. **Reproducibility**: Clone and recreate exact repository configuration
3. **Transparency**: Team can see and review setting changes
4. **Automation**: No manual UI interactions needed
5. **Disaster Recovery**: Follows the "spilled coffee principle"

## Implementation Steps

- [ ] Research all available GitHub API settings endpoints
- [ ] Design YAML schema for settings file
- [ ] Create GitHub Action workflow
- [ ] Add validation logic
- [ ] Test with non-critical settings first
- [ ] Document the system
- [ ] Consider creating a reusable action for other repos

## Related Principles

- **systems-stewardship**: Creating self-maintaining infrastructure
- **spilled-coffee-principle**: Full reproducibility from source
- **versioning-mindset**: Settings evolve with the repository
- **transparency-in-agent-work**: All configuration visible in source

## Priority

Low - The immediate need (description update) has been addressed manually. This is a longer-term improvement for robust repository management.

## References
- [GitHub REST API - Update a repository](https://docs.github.com/en/rest/repos/repos#update-a-repository)
- [GitHub Settings App](https://github.com/apps/settings) - Similar concept as a GitHub App
- Infrastructure as Code principles

Start by researching the GitHub REST API repository-settings endpoints and the proposed .github/repository-settings.yml schema. Then review the planned .github/workflows/sync-repository-settings.yml workflow; done means an agreed configuration is validated, applied through the API, failures are reported, and the system is documented.

Written by the indexing model from the issue text.