fix(calendar): keep default creation transactional

[RaresKeY]

Summary

Keep lazy default-calendar creation inside the caller's transaction. The helper
now flushes the new row without committing it, so a failed event request rolls
back both the event and the default calendar instead of leaving an orphan.

Callers that intentionally materialize a default during calendar reads commit
explicitly. Stable fallback IDs handle supported username rename/reuse without
breaking concurrent first use or caller rollback. Existing-calendar behavior
is unchanged.

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #5641

Part of #5637

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)
• New feature (non-breaking — adds new behaviour)
• Breaking change (changes or removes existing behaviour)
• Refactor / cleanup (behaviour unchanged)
• Documentation only
• CI / tooling / configuration

Checklist

• I searched open issues and open PRs — this lazy default-calendar transaction bug is not already owned.
• This PR targets dev.
• My changes are limited to default-calendar transaction ownership and focused regressions.
• I ran the app end-to-end. Route/helper transaction behavior was validated with isolated database tests.

How to Test

1. Run:

   python -m pytest -q tests/test_calendar_default_transaction.py tests/test_calendar_owner_scope.py

2. Create an invalid event for an owner with no calendar and verify neither a calendar nor event remains after rollback.

3. Create a valid event and verify its newly created default calendar commits with it.

4. List calendars for an owner with no calendar and verify the intentional lazy default is committed.

5. Rename that owner, recreate the old username, and verify lazy creation uses one stable fallback calendar under concurrent first use.

Exact-head validation passes 77 focused/rename tests and 189 calendar, CalDAV,
and rename tests plus Python compilation. The full repository result matches
the clean-dev baseline; live external-database coverage remains a reviewer
item.

Visual / UI changes — REQUIRED if you touched anything that renders

No visual or frontend files changed.

• Screenshot or short clip — not applicable; no rendering changed.
• Style match — no UI change.
• No new component patterns.
• I am not an LLM agent submitting a bulk PR. Contributor attestation remains for the human author.