fix(profile): member delete must not destroy the shared account

[paulocastellano]

Closes #50.

Bug

Members joining via workspace invite share the owner's account_id. `ProfileController::destroy` was unconditionally calling `$account->delete()` in every profile-deletion path, so any member could wipe the whole organization — workspaces, posts, social accounts, signatures, labels — just by clicking Delete on their own profile.

Fix

Gate the account/subscription teardown behind `isAccountOwner()`. For members the destroy path now only detaches them from workspaces and deletes the user row. Owner's data is untouched.

- if ($account) {
-     $account->delete();
- }
+ if ($account && $isOwner) {
+     if ($account->subscribed(Account::SUBSCRIPTION_NAME)) {
+         $account->subscription(Account::SUBSCRIPTION_NAME)->cancelNow();
+     }
+     $account->subscriptions()->delete();
+     $account->delete();
+ }

(Subscription cancellation moved into the same gate — it's an owner-only concern; for a member there's no subscription to touch.)

Tests

3 new tests, each parametrized over `SELF_HOSTED=true` and `false` (6 runs total):

• Member deletes profile → shared account, workspace, owner all survive.
• Member deletes profile → detached from workspace memberships.
• Owner deletes profile → cascade still works (account + workspace gone).

Both modes pass because the path no longer depends on `self_hosted` — `isAccountOwner()` is a pure model check, and `$account->subscribed(...)` returns false on self-hosted (no Stripe records), so the cancel/delete-subscription calls naturally no-op.

Full suite: 1603 passing.

🤖 Generated with Claude Code