hub_send.py marker path was __file__-relative: correct only because the unit names the symlink, and it reported landed registrations as failures

FIXED+PUSHED 2026-08-01 (sh.git d706e22). Found by bin-venus-cc while checking whether the report.py DB-path bug had copies. hub_send.py:22 had REGISTER_MARKER = Path(__file__).parent.parent / 'data' / '.hub_registered_at'. The file lives in the sh.git checkout ~/.local/bin/monitor-context/ and is also reachable via the ~/agents/monitor-context/scripts symlink; Python leaves __file__ as the invocation path, so this resolved correctly ONLY because context-venus-tick.service happens to name the symlink. Invoked by its true path it becomes ~/.local/bin/data/, which does not exist, and .touch() has no parents=True -> FileNotFoundError raised INSIDE register() AFTER the hub POST already succeeded: agent registered, caller sees register-failed, marker never written, every subsequent tick re-registers and triggers the fleet-wide pruneStale() scan that register_if_stale()'s own comment exists to avoid. Two fixes: (1) MONITOR_CONTEXT_DATA_DIR env override defaulting to the absolute data dir, so the file's correctness no longer depends on which path a unit names; (2) marker write wrapped - a marker failure can NEVER be reported as a registration failure, since the POST has already landed. Verified: marker resolves identically via both import paths. Third instance of __file__-relative paths in this subtree (tick.py, scan-context.py, report.py were the others).