Epic: Migrate from com.netflix.conductor to org.conductoross.conductor namespace

## Motivation

Conductor OSS is no longer maintained by Netflix and is now an independent open-source project maintained by the community. The package namespace should reflect this ownership change:

- **Current (legacy)**: `com.netflix.conductor.*` - implies Netflix ownership
- **Target (modern)**: `org.conductoross.conductor.*` - reflects community ownership

This epic tracks the incremental migration of all modules to the new namespace.

## Current State

The codebase is in a **mixed state** with both namespaces:

### ✅ Fully Migrated (5 modules)

| Module | Status | Notes |
|---|---|---|
| `os-persistence-v2` | ✅ Complete | New module (PR #749) |
| `os-persistence-v3` | ✅ Complete | New module (PR #749) |
| `common` (partial) | 🔄 In Progress | Some new models use new namespace |
| `core` (partial) | 🔄 In Progress | New execution/task code uses new namespace |
| `rest` (partial) | 🔄 In Progress | Some controllers migrated |

### ❌ Not Yet Migrated (34 modules)

**Core Infrastructure** (7):
- [ ] `annotations`
- [ ] `annotations-processor`
- [ ] `server`
- [ ] `server-lite`
- [ ] `grpc`
- [ ] `grpc-server`
- [ ] `grpc-client`

**Persistence Backends** (6):
- [ ] `cassandra-persistence`
- [ ] `redis-persistence`
- [ ] `mysql-persistence`
- [ ] `postgres-persistence`
- [ ] `sqlite-persistence`
- [ ] `es7-persistence`

**Storage** (3):
- [ ] `awss3-storage`
- [ ] `azureblob-storage`
- [ ] `postgres-external-storage`

**Event Queues** (6):
- [ ] `awssqs-event-queue`
- [ ] `kafka-event-queue`
- [ ] `amqp`
- [ ] `nats`
- [ ] `nats-streaming`
- [ ] `kafka`

**Tasks & Extensions** (4):
- [ ] `http-task`
- [ ] `json-jq-task`
- [ ] `workflow-event-listener`
- [ ] `task-status-listener`

**Locking & Concurrency** (2):
- [ ] `redis-lock`
- [ ] `redis-concurrency-limit`

**Metrics** (1):
- [ ] `metrics`

**Testing** (2):
- [ ] `test-util`
- [ ] `test-harness`

**Deprecated Stubs** (3):
- [ ] `os-persistence` (deprecation stub - low priority)
- [ ] `es6-persistence` (deprecation stub - low priority)
- [ ] `common-persistence` (interface only)

## Migration Strategy

### Approach Options

**Option 1: Big Bang Migration** ❌
- Migrate everything at once
- **Risk**: Massive PR, high chance of conflicts, difficult to review
- **Not recommended**

**Option 2: Incremental Module-by-Module** ✅ **Recommended**
- Migrate one module at a time or related groups
- Create PRs for each module/group
- Allows gradual testing and review
- Can prioritize based on activity/importance

**Option 3: New Code Only** 🔄 **Current State**
- Only new modules use new namespace (current approach)
- Legacy modules stay as-is indefinitely
- **Issue**: Creates permanent inconsistency

### Recommended Migration Order

1. **Phase 1: New Modules** ✅ **COMPLETE**
- Start with brand new modules (os-persistence-v2/v3)
- Sets precedent for new development

2. **Phase 2: Least-Dependent Modules**
- `metrics` - utility module
- `redis-lock` - standalone utility
- `redis-concurrency-limit` - standalone utility
- Low risk, low impact

3. **Phase 3: Storage/Queue Modules**
- Event queues: `kafka-event-queue`, `awssqs-event-queue`, `amqp`, `nats`, etc.
- Storage: `awss3-storage`, `azureblob-storage`, `postgres-external-storage`
- Can be done in parallel since they're independent

4. **Phase 4: Persistence Backends**
- `sqlite-persistence`
- `postgres-persistence`
- `mysql-persistence`
- `cassandra-persistence`
- `redis-persistence`
- `es7-persistence`

5. **Phase 5: Task Extensions**
- `http-task`
- `json-jq-task`
- `workflow-event-listener`
- `task-status-listener`

6. **Phase 6: Core Infrastructure**
- `annotations` (many dependents)
- `annotations-processor`
- `rest` (finish partial migration)
- `grpc-*` modules

7. **Phase 7: Core & Common** (Last)
- `common` (finish partial migration)
- `core` (finish partial migration)
- Most dependencies - highest risk
- Wait until everything else is migrated

8. **Phase 8: Server**
- `server`
- `server-lite`
- Final cleanup

### Migration Checklist (Per Module)

When migrating a module:

- [ ] Update package declarations
- [ ] Update imports
- [ ] Move directory structure
- [ ] Update build.gradle if needed (shading, etc.)
- [ ] Run `spotlessApply` to fix formatting
- [ ] Verify tests pass
- [ ] Update any documentation/README
- [ ] Create PR with clear description
- [ ] Get review and merge

## Considerations

### Breaking Changes
- **Public API**: Changing package names is a breaking change for external users
- **Mitigation**: Use semantic versioning (major version bump)
- **Deprecation**: Could keep old packages with `@Deprecated` forwarding to new ones

### Dependencies
- Some modules import classes from other modules
- Must track dependency graph to migrate in correct order
- Low-dependency modules should go first

### Testing
- Each module must have passing tests after migration
- Integration tests may need updates if they reference package names

### Documentation
- Update any docs that reference old package names
- Add migration guide for external users

## Benefits

1. **Clear ownership**: Package name reflects actual maintainers
2. **Consistency**: All code uses same namespace
3. **Future-proof**: Correct foundation for future development
4. **Professional**: Shows project is independent and mature

## Related

- PR #749 - First modules migrated (os-persistence-v2/v3)
- Review by v1r3n requesting new namespace for new modules

## Notes

- This is a **long-term effort** that can span multiple releases
- **New modules should always use** `org.conductoross.conductor` namespace
- **Low priority** - functional improvements take precedence
- Can be done opportunistically when modules are already being modified
- Community contributions welcome for individual module migrations

---

**Progress: 5/39 modules migrated (~13%)**