a more agentic sibling to `btw_app()`

Just jotting some notes down from an internal conversation. tl;dr: btw_app() should have a sibling with a more agentic, "Claude Code Dupe" feel.

As of now, side::kick() is a separate package implementing something like this Claude Code Dupe idea:

• It has a run_r_code() and bash() tool that are registered automatically and, in most cases, do not require approval.
• It has more direct prompting about poise and feel that tell it to "just do stuff and say as little as possible."
• There's no setup flow other than installing the package--the app can discover providers and register them in a persistent way.

That said, side::kick() is quite scrappy and does all sorts of naughty namespacing tricks to make things happen. Because of this, 1) ellmer and shinychat and btw do not benefit when something gets implemented in side::kick(), and 2) side::kick() doesn't benefit when ellmer and shinychat and btw do things the right way.

These issues could be resolved by a sibling to btw_app() that is less configurable and more agentic, e.g. btw::btw_agent() or btw::sidekick() or otherwise. btw_app() can remain a more tailored-to-fit / safe interface to the suite of tools that btw provides.

Start by reading the existing btw_app() interface and the side::kick() behavior described in the issue, then compare how ellmer and shinychat integrate with btw. Done would require a decided sibling API and agreed scope for its more agentic behavior, setup flow, and tool approvals.