[ENHANCEMENT]: for update and for update skip locked to support entry level lock and db as queue

[kidlj]

Feature Description

1. select... for update to support entry level lock and
2. select... for update skip locked to use database as queue.

[hiSandog]

For FOR UPDATE / FOR UPDATE SKIP LOCKED, the important part to define up front is dialect and transaction behavior. It would help a future PR if the issue listed which databases should support the API first, what should happen outside an explicit transaction, and whether unsupported dialects should fail at compile/build time or return a runtime error.

[lroal]

Thanks for the suggestion. I'll take a look at it and think about an API that works well across the supported databases. I'll post a proposal for the API syntax before implementing anything.

Also, if you find Orange ORM useful, I'd really appreciate a ⭐ on the repository. It helps increase the project's visibility and encourages further development.

[lroal]

Proposed support matrix

Database	forUpdate	skipLocked	Strategy
PostgreSQL	✅ Supported	✅ Supported	FOR UPDATE / FOR UPDATE SKIP LOCKED
MySQL 8+ / InnoDB	✅ Supported	✅ Supported	FOR UPDATE / FOR UPDATE SKIP LOCKED
MariaDB 10.6+ / InnoDB	✅ Supported	✅ Supported	FOR UPDATE / FOR UPDATE SKIP LOCKED
Oracle	✅ Supported	✅ Supported	FOR UPDATE / FOR UPDATE SKIP LOCKED
SQL Server	✅ Supported	✅ Supported	WITH (UPDLOCK) / WITH (UPDLOCK, READPAST, ROWLOCK)
SQLite	❌ Unsupported	❌ Unsupported	Throw runtime error
SAP ASE	❌ Unsupported	⚠️ Maybe later	readpast can skip locked rows, but there is no clean FOR UPDATE equivalent

### Proposed API syntax

```ts
await db.transaction(async tx => {
  const jobs = await tx.job.getMany({
    where: x => x.status.eq("pending"),
    forUpdate: true,
    skipLocked: true,
  });

  for (const job of jobs) {
    job.status = "processing";
  }

  await jobs.saveChanges();
});

getMany() is only one example here. The intention is that forUpdate and skipLocked should be supported by the relevant Orange methods that accept a strategy, including related tables inside the strategy where this makes sense.

For example:

const orders = await db.order.getMany({
  forUpdate: true,
  skipLocked: true,

  customer: {
    forUpdate: true,
  },

  lines: {
    orderBy: "product",
    forUpdate: true,

    packages: {
      forUpdate: true,
    },
  },
});

For unsupported databases, Orange should throw a runtime error rather than silently ignoring the option. Silent ignore would be dangerous because users may believe they have locking semantics when they do not.

The forUpdate is intended to be used inside an explicit transaction. Outside a transaction, many databases will release the lock immediately after the statement completes due to autocommit behavior - but I don't think Orange should raise an error if used in such a way.

For TypeScript design-time support, my current preference is to keep the strategy API database-agnostic. In other words, forUpdate and skipLocked would exist in the common strategy type even for dialects that do not support them. That keeps the API simpler and avoids having to maintain different strategy types per database adapter. Unsupported dialects can instead fail at runtime with a clear error message.