Fix migrated repository and planning links in contributor entry points

[dstkwll]

Problem

Current contributor entry points still direct new contributors to shyamsridhar123/ecorp and personal Project #3. The canonical repository is All-The-Vibes/ecorp; ECorp Build / organization Project #5 identifies itself as the destination for new work, with its September 11 cutover notice preserving existing Project #3 execution lineage.

At main b2523964e7576cafc00e84a51e1044f55826dea7, this affects clone commands, Cargo repository metadata, issue links, and planning/contributor guidance.

Scope

Review and correct current contributor references in:

• Cargo.toml
• README.md
• CONTRIBUTING.md
• docs/README.md
• docs/PRODUCT_AND_TECHNICAL_PLAN.md
• docs/USER_AND_DEVELOPER_JOURNEY.md
• docs/DARK_FACTORY_CONTRIBUTOR_GUIDE.md

Acceptance criteria

• Current repository metadata, clone instructions and current issue links use All-The-Vibes/ecorp.
• New-work planning instructions link to organization Project Implement resumable browser event streams with sequence cursors #5 and use its correct owner/number where applicable.
• Existing claims, missions, recoveries and publication history associated with personal Project Build the deterministic child-process agent adapter #3 retain their original authority and identities. Retained historical references are clearly labeled.
• Planning guidance distinguishes the new-work destination from each operator's configured execution authority; it does not imply shared claim authority across independent control planes or silently change runtime defaults.
• The seven entry points are consistent, Markdown links and command examples are reviewed, and applicable repository checks pass.

Related work and boundaries

#232 addresses Factory membership lookup and canonical issue identity, not these contributor entry points. #161 / PR #255 address shared claim authority; this cleanup does not implement or declare that work complete. #269 records the same new-work versus historical-lineage distinction.

No runtime, migration, historical evidence-file, board-restructuring, or broad repository-wide replacement is included. Start with a bounded isolated-worktree contribution and reviewable Git patch. Publication, merge and deployment remain separate actions.