fix(create-site): update scripts for creating site + publishing

[seaerchin]

NOTE: do not merge till release as this will go into effect IMMEDIATELY

Problem

https://opengovproducts.slack.com/archives/C06R4DX966P/p1736928912803439

1. studio and components use different properties for siteName - which in turns impact the footer
2. createSite.ts has a default siteName set, even though the script already gives a siteName

Solution

1. remove the spread in property - the config object already has siteName
2. use the passed in siteName for createSite

Tests

1. create a site locally using createSite.ts
2. verify that the site has a correct siteName and not the default of MTI
3. point a staging site to this branch
4. update teh staging db so that the site's site.name and site.config.siteName differ
5. publish a change
6. verify that the end site uses site.config.siteName

[datadog-opengovsg]

Datadog Report

Branch report: fix/create-site
Commit report: 6fbda92
Test service: isomer-studio

❌ 3 Failed (0 Known Flaky), 189 Passed, 36 Skipped, 42.4s Total Time
⬆️ Test Sessions change in coverage: 1 increased (+7.29%)

❌ Failed Tests (3)

• site.router list should include the Site if the user has any role permission for the site - apps/studio/src/server/modules/site/__tests__/site.router.test.ts - Details

  Expand for error

   expected [ { id: 1, config: { …(4) } } ] to deeply equal [ { id: 1, …(2) } ]
  

• site.router list should only include sites that the user has any role permission for - apps/studio/src/server/modules/site/__tests__/site.router.test.ts - Details

  Expand for error

   expected [ { id: 2, config: { …(4) } } ] to deeply equal [ { id: 2, …(2) } ]
  

• site.router list should only show a site once if there are multiple permissions for the same site and user - apps/studio/src/server/modules/site/__tests__/site.router.test.ts - Details

  Expand for error

   expected [ { id: 5, config: { …(4) } } ] to deeply equal [ { id: 5, …(2) } ]
  

[dcshzj]

issue: I recall we did this so that we store the site name as a separate column inside the DB rather than inside the JSON column, as it is used under the sites dashboard. We couldn't remove the siteName prop inside the JSON blob because then the types would not match.

I think we should still stick to storing the site name in the separate column and have this set to say "Ignore this" (until we have a good solution for the typing mismatch).

[seaerchin]

issue: I recall we did this so that we store the site name as a separate column inside the DB rather than inside the JSON column, as it is used under the sites dashboard. We couldn't remove the siteName prop inside the JSON blob because then the types would not match.

can clarify this? not sure what the issue here is apart from the types - if it's just about the name that presents on the dashboard, we can also chagne it to read from site.config.siteName, which i thought is better because that's a "user level view" whereas the db one (site.name) is not tied under site.config

[dcshzj]

Oh yeah it would be perfect if we can read directly from site.config.siteName but not sure if there is any performance impact reading from JSON blobs.

[seaerchin]

ok then i'll just make the change to read directly from site.config.siteName HAHA

[seaerchin]

done, see video here. re: performance impact - it's close to 0 because we already read it at present lol

Screen.Recording.2025-01-15.at.5.33.02.PM.mov