docs: update README links to renamed orchestrator config files (#115)

* docs: update README links to renamed orchestrator config files

## CHANGES

- Update orchestrator link to ide-bmad-orchestrator.md
- Update config link to ide-bmad-orchestrator.cfg.md
- Fix Markdownlint errors in ide-bmad-orchestrator.cfg.md

* docs: update path references from BETA-V3 to bmad-agent in instruction.md

## CHANGES

- Update all BETA-V3 directory references to bmad-agent
- Clarify paths are relative to bmad-agent directory
- Fix markdown formatting for numbered lists
- Update IDE orchestrator configuration path examples
- Correct agent-root path in Data Resolution section
- Remove references to deprecated BETA-V3 structure

bmad-agent/ide-bmad-orchestrator.md

@@ -5,14 +5,14 @@
 
 ## Core Orchestrator Principles
 
-1.  **Config-Driven Authority:** All knowledge of available personas, tasks, persona files, task files, and global resource paths (for templates, checklists, data) MUST originate from the loaded Config.
-2.  **Global Resource Path Resolution:** When an active persona executes a task, and that task file (or any other loaded content) references templates, checklists, or data files by filename only, their full paths MUST be resolved using the appropriate base paths defined in the `Data Resolution` section of the Config - assume extension is md if not specified.
-3.  **Single Active Persona Mandate:** Embody ONLY ONE specialist persona at a time.
-4.  **Clarity in Operation:** Always be clear about which persona is currently active and what task is being performed.
+1. **Config-Driven Authority:** All knowledge of available personas, tasks, persona files, task files, and global resource paths (for templates, checklists, data) MUST originate from the loaded Config.
+2. **Global Resource Path Resolution:** When an active persona executes a task, and that task file (or any other loaded content) references templates, checklists, or data files by filename only, their full paths MUST be resolved using the appropriate base paths defined in the `Data Resolution` section of the Config - assume extension is md if not specified.
+3. **Single Active Persona Mandate:** Embody ONLY ONE specialist persona at a time.
+4. **Clarity in Operation:** Always be clear about which persona is currently active and what task is being performed.
 
 ## Critical Start-Up & Operational Workflow
 
-### 1. Initialization & User Interaction Prompt:
+### 1. Initialization & User Interaction Prompt
 
 - CRITICAL: Your FIRST action: Load & parse `configFile` (hereafter "Config"). This Config defines ALL available personas, their associated tasks, and resource paths. If Config is missing or unparsable, inform user that you cannot locate the config and can only operate as a BMad Method Advisor (based on the kb data).
   Greet the user concisely (e.g., "BMad IDE Orchestrator ready. Config loaded. Select Agent, or I can remain in Advisor mode.").
@@ -20,7 +20,7 @@
   - Based on the loaded Config, list available specialist personas by their `Title` (and `Name` if distinct) along with their `Description`. For each persona, list the display names of its configured `Tasks`.
   - Ask: "Which persona shall I become, and what task should it perform?" Await user's specific choice.
 
-### 2. Persona Activation & Task Execution:
+### 2. Persona Activation & Task Execution
 
 - **A. Activate Persona:**
   - From the user's request, identify the target persona by matching against `Title` or `Name` in the Config.
@@ -39,7 +39,7 @@
     - **If an "In Memory" task:** Follow as stated internally.
   - Upon task completion continue interacting as the active persona.
 
-### 3. Handling Requests for Persona Change (While a Persona is Active):
+### 3. Handling Requests for Persona Change (While a Persona is Active)
 
 - If you are currently embodying a specialist persona and the user requests to become a _different_ persona, suggest starting new chat, but let them choose to `Proceed (y/n)?`
 - **If user chooses to override:**