start_remote() auto-registers @remote_command methods

[dccote]

Summary

Simplifies the remote API surface based on feedback. start_remote() now auto-registers @remote_command-tagged methods, so register_remote_commands() no longer needs to be called manually:

class MyApp(App, RemoteControllable):
    @remote_command
    def turn_on(self): ...

app = MyApp(name="Server")
app.start_remote()     # tagged methods are registered automatically
app.mainloop()

Why not just remove app.remote?

app.remote() isn't a parallel feature to @remote_command — it's the engine underneath it. register_remote_commands() calls self.remote(...) for each tagged method, so it can't be deleted. Instead this PR reframes it: docs now present @remote_command as the way to expose methods, and app.remote(...) as the low-level primitive it builds on (still there for free functions or dynamic runtime registration). Nothing is removed; fully backward compatible.

Changes

• start_remote() calls register_remote_commands() before publishing (idempotent — remote() overwrites by name).
• register_remote_commands() documented as auto-called / rarely needed.
• Module + method docstrings lead with @remote_command; remote() reframed as the primitive.
• No API removed; existing self.remote(...) / @app.remote usage still works.

Tests

• New test_start_remote_auto_registers_commands (tagged methods exposed with no explicit register call).
• CLI tests dropped their explicit register_remote_commands() to exercise auto-registration through start_remote.
• Full suite green.

Targeted for release v1.7.1 (backward-compatible refinement).

🤖 Generated with Claude Code