Fix the unforced subscription change path

[johnworth]

Stacked on #70 — review that one first. The base will retarget to main
automatically when #70 merges.

The bug

POST /v1/subscriptions?force=false failed for every request and answered
200 while doing it, so terrain's POST /terrain/admin/qms/subscriptions
silently created nothing whenever force wasn't set. The upgrade-comparison
rule the unforced path exists to implement has therefore never actually run.

Two defects, both on that path:

1. An unbound placeholder. GetActiveSubscriptionForDate built

db.Where("? BETWEEN subscriptions.effective_start_date AND subscriptions.effective_end_date", date).
    Or("? > subscriptions.effective_start_date AND subscriptions.effective_end_date IS NULL")

with no argument for the second ?, so PostgreSQL rejected the statement with
syntax error at or near ">". The handler wrapped that into a per-item
failure_reason and still returned 200.

The clause is meaningful rather than dead — effective_end_date is nullable,
and the sibling GetActiveSubscription covers the same case with a
CURRENT_TIMESTAMP literal — so this binds date rather than dropping it.
The two functions were clearly the same query with the literal swapped for a
placeholder, and one swap lost its argument.

2. A nil dereference the first fix exposes. With the query working, a user
who has no subscription as of the start date reaches

activeCPUAllocation := activeSubscription.Plan.GetDefaultQuotaValue(...)

with activeSubscription == nil, because GetActiveSubscriptionForDate
returns (nil, nil) when there's no match and GetUser only upserts the user
row without subscribing them. That panics; echo's recover middleware turns it
into a 500.

Verified rather than assumed — reverting just the guard and re-running
TestUnforcedSubscriptionForNewUser panics at subscriptions.go:117. So
fixing the query alone would have traded a silent no-op for a failure on every
new user, which is arguably worse than the original bug.

A missing subscription can't be a downgrade, so the request now proceeds to
create one.

Tests

The test that pinned the broken behavior is replaced by the matrix the rule
actually describes:

starting	requested	outcome
Basic	Pro	upgraded — new_subscription: true, active plan Pro
Pro	Basic	refused — new_subscription: false, active plan Pro
Pro	Pro	refused — new_subscription: false, active plan Pro
(none)	Pro	subscribed — new_subscription: true, active plan Pro

Each asserts the active subscription in the database as well as the response,
since that's what the rest of the DE reads.

go test ./... and golangci-lint run ./... (v2.12.2, the CI pin) are clean.

Not fixed here

The other two bugs #70 records are left alone so each fix stays reviewable on
its own: every updates row recording ADD even for a SET, and the bulk
endpoint storing a different username than every other endpoint. The latter
also implies existing databases hold duplicate users rows that need
reconciling, which is a data question as much as a code one.

🤖 Generated with Claude Code