fix: use fixed expiry for asymmetric JWT generation

[7ttp]

Summary

Running supabase status -o env multiple times produces different SERVICE_ROLE_KEY values on each invocation when using asymmetric signing keys.
This breaks workflows where the service role key needs to be stored in a vault or used consistently across multiple command runs.

Problem

When LoadConfig() is called (which happens on every supabase status run), it regenerates JWT keys.
For asymmetric keys, the expiry was set using time.Now().Add(10 years),
causing the JWT payload to have a different expiry timestamp on each generation:

• Run 1: exp: 2036-01-23 19:37:15
• Run 2: exp: 2036-01-23 19:37:16 (1 second later)

Different expiry → Different JWT payload → Different SERVICE_ROLE_KEY

Solution

Use the same fixed expiry constant (defaultJwtExpiry = 1983812996, expires Nov 2032) that symmetric keys already use.
This ensures the JWT payload remains identical across multiple generations.
This aligns asymmetric key behavior with symmetric keys (line 35)

Related

• Closes Local Supabase Service Role changing constantly #4751

[7ttp]

@aantti @sweatybridge

[sweatybridge]

This ensures the JWT payload remains identical across multiple generations.

We don't want to encourage users to rely on this behaviour. Each JWT should be validated against the JWT secret using one of the well known libraries. Direct string comparison is almost always a bad idea.

That said, I agree the current behaviour of status command is very misleading. It should read the last used JWT from the running container instead.