Add OpenCode.md to gitignore

What does this MR do and why?

Adds OpenCode.md to .gitignore to allow developers to maintain personal configuration files for AI coding assistants without committing them to the repository.

This enables developers to:

• Store personal preferences (username, communication style, etc.)
• Document project-specific conventions for AI tools
• Keep configuration local to their development environment

Context

OpenCode has been a surprisingly effective development tool for working with the GitLab codebase. Having a personal configuration file allows the AI assistant to understand project-specific conventions, commit message formats, and workflow preferences without needing to explain them repeatedly.

For examples of OpenCode in action with GitLab, see this Slack thread with demo videos.

Example Configuration

Example OpenCode.md configuration (click to expand)

# OpenCode Configuration for GitLab

## User Information
- **GitLab Username:** ghavenga
- **GitLab Instance:** gitlab.com
- **Project:** gitlab-org/gitlab

## Environment
- GitLab API access token is available in environment variables
- Use `glab` CLI for GitLab API interactions

## Communication Guidelines

### GitLab Interactions
- **NEVER** comment on merge requests or issues unless explicitly requested
- When asked to comment, always show the proposed comment and wait for approval/denial before posting
- Use `glab api` commands for read-only operations (checking status, fetching data)

### Git Workflow
- Default branch: `master`
- Only create commits when explicitly requested
- Only push changes when explicitly requested
- Follow Git Safety Protocol in the system instructions

### Commit Conventions
- Start commit messages with a capital letter
- Keep commit subject lines under 72 characters (73 max)
- Use descriptive, concise messages that explain the change to someone with zero context
- Add changelog trailers when applicable:
  - `Changelog: added|changed|deprecated|removed|fixed|security|performance|other`
  - `EE: true` for Enterprise Edition-only changes
  - See https://docs.gitlab.com/ee/development/changelog.html for details
- Example commit with trailers:

---
Fix tooltips in mini pipeline graph

Update the tooltip behavior to correctly display pipeline status information when hovering over pipeline icons.

Changelog: fixed
---


### Branch Naming
- Prefix all branches with username: `ghavenga-feature-name`
- Use descriptive names: `ghavenga-fix-pipeline-tooltips`
- Keep branch names concise and kebab-case

## GitLab-Specific Guidelines

### Merge Requests
- When reviewing MRs, use GitLab API to:
- Check pipeline status
- Review discussions/notes
- Examine diffs and changes
- Never auto-approve or comment without explicit permission
- When asked to work on an MR:
1. Fetch and checkout the branch
2. Review the context (description, discussions, pipeline)
3. Make requested changes
4. Run tests locally when applicable

### Database Work
- This is the GitLab Development Kit (GDK) repository
- Database schema in `db/structure.sql`
- Migrations in `db/migrate/` and `db/post_migrate/`
- Test database is available via GDK

### Code Style
- Follow GitLab development guidelines
- Ruby: RuboCop is configured
- JavaScript/Vue: ESLint and Prettier are configured
- Run linters before committing (handled by lefthook)

### Testing
- RSpec for Ruby tests
- Jest for JavaScript tests
- Run relevant tests before pushing changes
- Check for test failures in pipeline

## Common Tasks

### Working on a GitLab Issue or MR
1. Fetch issue/MR details using `glab api`
2. Create or checkout appropriate branch
3. Implement changes following GitLab conventions
4. Run relevant tests
5. Commit with descriptive messages
6. Push only when explicitly asked

### Reviewing Assigned Work
- Use GraphQL API to fetch assigned MRs/issues
- Review todos and action items
- Provide analysis and recommendations
- Take action only when explicitly directed

## Notes
- GitLab has extensive CI/CD pipelines - be patient with pipeline results
- Danger bot will comment on MRs with warnings - these are often non-blocking
- EE (Enterprise Edition) changes require `ee: true` in changelog entries
- This repository is very large - use targeted searches and glob patterns

Open Question

Would it be valuable to include an OpenCode.md.template in the repository as a starting point for other developers? Happy to discuss during review.

MR acceptance checklist

• Single line change to .gitignore
• No impact on existing workflows
• Follows existing gitignore patterns