Decide: Whether to pursue Rubber Duck availability in app and CLI agent sessions

Decision requested

Should this repository pursue platform-supported Rubber Duck access for its app/CLI agent sessions, or retain the documented unavailable-tool fallback without an enablement investigation? If pursuing it, the owner must name the target surface/session types, who owns the platform inquiry, and the scope of any separately authorized investigation. This issue records the question; it does not choose an option or authorize implementation.

Derived from: #149, #119.

Context and evidence

• Epic #119 owner decision explicitly separates a documentation-only retro fix from this platform question: https://github.com/mochan-tk/agentic-dev-kit-for-copilot/issues/119#issuecomment-5740948383 .
• #149 occurrence 1: https://github.com/mochan-tk/agentic-dev-kit-for-copilot/issues/136#issuecomment-5739332583 . Occurrence 2: https://github.com/mochan-tk/agentic-dev-kit-for-copilot/issues/119#issuecomment-5739073572 . Count-2 record: https://github.com/mochan-tk/agentic-dev-kit-for-copilot/issues/149#issuecomment-5740013537 . These establish absence from those sessions' exposed tools, not a universal platform limitation.
• At origin/main 116e51debc79ab44fa573cf202a7598d8f76283a, .github/instructions/code-review.instructions.md and .github/skills/verification/SKILL.md describe supported-surface in-loop Rubber Duck separately from generic code review, Task-contract audit, and human approval. Documentation about a supported product surface does not prove a particular agent session exposes the mechanism.
• The approved documentation Task makes unavailable-tool handling explicit: state it once and avoid repeated boilerplate, without claiming execution or removing the remaining review duties. Its implementation does not depend on resolving this platform question.

Decision boundaries

• Needs an owner judgment, not an agent choice. No preferred outcome is recorded here.
• This is not a Task, has no ai:ready or exec label, and is not dispatched. No platform setting, tool grant, model, workflow, credential, or review requirement is changed.
• A future owner decision must distinguish documented support, session-tool exposure, and an actually observed run. Do not claim enablement from documentation alone, manufacture a substitute Rubber Duck run, or treat AI output as formal human approval.
• No experiment, new session, platform contact, or installation is authorized by filing this issue. Any follow-through needs its own scope and execution authorization.

Start by reading issues #149 and #119, then review .github/instructions/code-review.instructions.md and .github/skills/verification/SKILL.md. Done means an owner records whether to pursue Rubber Duck access, identifies the target session surfaces and platform-inquiry owner, and separately scopes any authorized investigation; filing this issue authorizes no experiment or implementation.