Polish README around the main REPL workflow instead of implementation history

[djdcks12]

Description

The project has grown into a small in-Editor runtime inspection and experimentation tool. The README should emphasize the user workflow more than implementation history or phase-by-phase details.

The current README is already useful, but 0.8.2 is a good point to tighten the narrative around the main loop:

1. Search or inspect a live object.
2. Pin or bind it to _.
3. Watch values that should keep updating.
4. Insert generated access code into the editor.
5. Validate before running risky code.
6. Patch a method temporarily when runtime behavior needs to change.

Why

Users coming from OpenUPM or GitHub want to quickly understand what problem the tool solves. Too much implementation detail can make the tool look more complex than it feels in use.

Suggested Fix

Restructure or lightly edit README sections so the first half is workflow-first:

• What it does.
• Install.
• Quick start.
• Core workflow.
• Feature guide.
• Safety/data handling.
• Troubleshooting.
• Menus/reference.

Keep implementation-heavy notes in CHANGELOG or lower README sections.

Acceptance Criteria

• README starts from user value and installation, not phase history.
• The core workflow is easy to understand in one read.
• Advanced caveats remain available but do not dominate the first screen.
• README_KR follows the same structure and tone.