fix: resolve target GameObjects through ObjectsHelper everywhere; add include_stack_trace to get_console_logs

[dehuaichendragonplus]

Why this change is needed

Several built-in tools resolved their target GameObject with a bare GameObject.Find call: assign_animator, assign_material, camera tools, create_prefab/unpack_prefab, get_object_memory, capture_multiview's target_name, select_object/focus_on_object, get_hierarchy's root_name, and UI-creation tools' parent_name. GameObject.Find cannot find inactive objects and has no way to disambiguate duplicate names -- so any of these tools silently failed or resolved the wrong object whenever the target was deactivated or shared its name with another object in the scene.

Separately, get_console_logs had no way to surface a logged error's stack trace, which made root-causing errors surfaced through the tool harder than necessary.

Change approach

• All of the tools above now resolve through the shared ObjectsHelper.FindTarget (name, hierarchy path, or instance ID; inactive objects and additively-loaded scenes included).
• Removes two now-redundant hand-rolled workarounds that existed only because the bare GameObject.Find call couldn't handle inactive objects: a recursive inactive-object search in HierarchyFunctions and a Resources.FindObjectsOfTypeAll fallback loop in UIFunctions.FindParent.
• get_console_logs gained an include_stack_trace option: appends each entry's stack trace (indented, own 2000-character truncation cap independent of the message's 300-character cap). Off by default.
• Rebuilt on top of v0.5.0 (post feat: save_to_file on screenshot tools, capture_editor_window, and raycast_at_point UI diagnostics #28/feat: real .snap memory snapshot tools + headless structured queries #29 merge) -- supersedes The type or namespace name `R' could not be found. Are you missing an assembly reference? #2, which targeted a now-stale base branch. ScreenshotFunctions.cs/UIFunctions.cs changes here are limited to the target-resolution call sites and leave the path-traversal hardening from feat: save_to_file on screenshot tools, capture_editor_window, and raycast_at_point UI diagnostics #28 untouched.

Benefits

• Every affected tool can now find inactive GameObjects and correctly disambiguate duplicate names, instead of silently failing or resolving the wrong target.
• Removes two duplicated, harder-to-maintain workarounds now that the shared resolver covers their case.
• Debugging a logged error is faster with an opt-in stack trace directly in get_console_logs output, without bloating the default (300-char message-only) response.
• Rebased cleanly onto the latest merged base (v0.5.0), avoiding the stale-branch conflicts that affected The type or namespace name `R' could not be found. Are you missing an assembly reference? #2.

Test results

Scenario	Result
Compile after pulling branch into a live project's embedded package	0 errors
Create GameObject, deactivate it, then select_object by name	Resolved correctly (old GameObject.Find would have failed)
create_button with parent_name set to that inactive GameObject	Produced expected hierarchy path (get_game_object_info confirmed Parent/Button)
Trigger a real Debug.LogError, then get_console_logs(include_stack_trace=true)	Returns the indented stack trace under the message

Compatibility testing

• include_stack_trace defaults to off, so existing get_console_logs callers see no change in response shape.
• ScreenshotFunctions.cs/UIFunctions.cs changes are scoped to the target-resolution call sites only; the path-traversal hardening landed in feat: save_to_file on screenshot tools, capture_editor_window, and raycast_at_point UI diagnostics #28 is untouched.
• Verified live in a Unity 6000.3.13f1 project via the MCP tools themselves (see Test results above), all going through a live running server.

Checklist

• I tested the package in a clean Unity 2022.3+ project (tested live in a Unity 6000.3.13f1 project via the MCP tools themselves: compiled clean, then exercised the actual runtime behavior -- see Test results)
• I verified Funplay > MCP Server opens and starts correctly (verified indirectly: all MCP tool calls above went through a live running server)
• If I changed setup, update, or config flows, I verified the affected flow end-to-end (N/A, no setup/update/config flow touched)
• I updated docs for any user-facing behavior changes (CHANGELOG updated; README/tool docs not touched)
• I did not commit local junk such as .idea/ or .DS_Store
• I updated CHANGELOG.md when the change affects users