fix(my_egeria): My Profile performance, exec_report_spec depth, packaging and serve fixes

[dwolfson]

Summary

Gets the new My Profile app ready to evaluate, in a terminal and in the Egeria-Workspaces portal. Its startup now shows the full profile about 4 s after the splash, down from about 82 s.

pyegeria

• exec_report_spec silently dropped graph_query_depth (ISSUE-119). It copies only a report spec's declared params, so params={..., "graph_query_depth": 0} always ran at the SDK default of 3. My Profile asked for depth 0 in about ten places and got none of it; live, several lists timed out at 90 s. Now graph_query_depth is forwarded when the target method accepts it. Other undeclared params are still not forwarded; this is deliberately narrower than the async path.
• Packaging (ISSUE-118). The wheel installed my_egeria one level too deep (site-packages/my_egeria/my_egeria/...), so my_egeria, my_profile, serve_my_egeria and serve_my_profile failed in every pip install. packages.find now also searches my_egeria/ with namespaces = false, and pyegeria/config and commands/deprecated gain __init__.py so they keep shipping. A clean-build file diff shows the wheel is otherwise identical, and my_profile.tcss now ships.
  • ⚠️ Downstream: anything launching the app by the old nested file path must switch to the entry points. The egeria-workspaces my-profile container does this today; a matching change there will follow.

my_egeria

• serve_my_*: these used the textual serve CLI from textual-dev, which is dev-only. They now use the textual-serve library and honour MY_EGERIA_PUBLIC_URL / MY_PROFILE_PUBLIC_URL. The stale [app.*] textual-web sections are removed.
• Startup check: it required EGERIA_SERVER / EGERIA_BASE_URL with no defaults, so the README's instructions ended in an error popup. It now derives them from the documented EGERIA_VIEW_SERVER / EGERIA_PLATFORM_URL.
• My Profile graph_query_depth (all live-measured):

Where	Change	Before → after
Startup "my collections"	depth 0	~70 s → 0.6 s
Profile	fetched once, formatted locally for both views (output verified identical)	2–3 fetches → 1
To-dos	depth as a keyword (params= was ignored)	5.7 s → 0.6 s
Shop for Data lists	depth 0 now takes effect (pyegeria fix)	~90 s timeouts → ~2 s
Glossary folders, root-collection members	fetch only the selected element at depth 1	needed once depth 0 took effect (the depth-0 list has no folders); also fixes the root-collection tree working only for the first row
Bookmarks, term/data-dictionary/collection details, subscriptions, comments, data-set GUID lookups	depth 0	bookmarks 30 s timeout → 0.3 s
Product and capability details	depth 1	they show members

Team members are unchanged, because they need depth 2 or more.

Docs

• The developer guide gains a section on choosing graph_query_depth.
• The my_egeria README now separates My Profile (the actively developed app) from the original MyEgeria app.
• Handoff and integration docs cover textual-serve, the packaging change and Python 3.13.
• The My Profile manual is updated.
• PYEGERIA_ISSUES.md: ISSUE-118 (packaging), ISSUE-119 (depth dropped), ISSUE-120 (Textual fails on Python 3.14, so use 3.13).

Testing

• New test_exec_report_spec_graph_query_depth.py: it fails without the fix. A new startup-check test was added, and the bookmarks test now pins graph_query_depth=0. The full tests/micro-tests and my_egeria tests pass.
• Live, against a 6.2-SNAPSHOT quickstart, as peterprofile:
  • my_egeria and my_profile run in a real terminal with no EGERIA_* variables set.
  • The profile is populated about 4.3 s after the splash, and Shop for Data works.
  • Depth-1 detail fetches return glossary folders (6 of 13 glossaries have them) and root-collection members.
• Textual: the new My Profile fails on Python 3.14 with both Textual 6.1.0 and 8.2.8, and runs on 3.13 with both.
• Not verified with live data: peterprofile has no to-dos, comments or bookmarks, so those three were checked against the report specs' columns.

🤖 Generated with Claude Code