fix: atomic position calculation in pin/channel creation

[gusye1234]

Summary

• Replaces two-step read-then-write position calculation with atomic subquery INSERT
• Prevents race condition where concurrent calls could get duplicate positions

Changes

• src/shared/src/db/queries/agent-pin.ts: pinAgent() now uses subquery for position
• src/shared/src/db/queries/channel.ts: createChannel() now uses subquery for position

Test plan

• Create two pins simultaneously and verify no duplicate positions
• Create two channels simultaneously and verify no duplicate positions

Closes #149

[gusye1234]

Review — PR #196: atomic position calculation in pin/channel creation

Good fix for a race condition in the position assignment logic. Moving from read-then-write to a single-statement subquery eliminates the window where concurrent inserts could read the same MAX and produce duplicate positions.

1. pinAgent: subquery computes MAX(position) + 1 within the INSERT VALUES — evaluated atomically before the row is inserted. onConflictDoNothing() still handles duplicate pin attempts.
2. createChannel: same pattern, scoped by workspaceId.
3. The COALESCE(..., -1) + 1 default ensures first position is 0, consistent with the prior logic.

The subquery-in-VALUES pattern is valid in both SQLite (D1) and PostgreSQL — the subquery is evaluated before the insert executes, so referencing the same table is safe.

Checklist:

• Functionality: eliminates duplicate position assignments under concurrency
• Edge cases: first-ever pin/channel still gets position 0
• Code quality: actually simpler than before (fewer statements)
• Code simplification: removed the separate SELECT query — net reduction in code
• Tests: CI green

LGTM — ready to merge.