sequelize-cli.config.js drifts from db.config.js on define.timestamps (false vs true)

[CryptoJones]

Problem

PR #148 flipped db.config.js's global define.timestamps from
false to true so every domain model inherits Sequelize's
auto-populated createdAt / updatedAt. The change matched the
de-facto convention (every model in app/models/ already declared
timestamps: true explicitly) and let new models drop the override.

But the runtime config and the CLI config live in two files, and
app/config/sequelize-cli.config.js was not updated alongside:

// app/config/db.config.js  (post-#148)
define: { schema: 'dbo', timestamps: true }

// app/config/sequelize-cli.config.js  (still pre-#148)
define: { schema: 'dbo', timestamps: false }

Today this isn't a behavioral bug — migrations use queryInterface
directly and never consult the define defaults. But two adjacent
config files declaring opposite values is a latent footgun:

• A future contributor adding model-based logic to a migration (e.g.
  a data-fixup migration that loads rows via db.Customer.findAll)
  would inherit different createdAt/updatedAt behavior under
  npm run migrate than under npm start.
• A reader trying to understand "what's the global default?" sees
  conflicting answers.

Fix

Flip sequelize-cli.config.js to timestamps: true to match the
runtime. Add a unit test pinning both define.timestamps and
define.schema agreement across the two configs so a future drift
surfaces as a CI failure.

Acceptance

• sequelize-cli.config.js declares define.timestamps: true
• A test asserts cliConfig.<env>.define.timestamps === dbConfig.sequelize.options.define.timestamps
• Same for define.schema

Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/