Add agentic CI-scan workflows with pooled Copilot token authentication

[kotlarmilos]

Adds the agentic CI workflows and moves their Copilot authentication onto an isolated, pooled token setup, in one change.

Workflows

• Add ci-scan and ci-scan-feedback agentic workflows, plus shared/ci-scan.instructions.md.
• Keep the existing libtorch-bump workflow.

Pooled Copilot authentication

• Each run selects a token from a COPILOT_PAT_0..9 pool within a dedicated copilot-pat-pool environment, via a shared shared/pat_pool.md import.
• Add a daily validate-pat-pool workflow.
• The pool fails fast (::error:: + exit 1) when no COPILOT_PAT_# secret is configured, so a run never falls through to an invalid literal token.
• ci-scan, ci-scan-feedback, and libtorch-bump all authenticate through the pool.

Requires the copilot-pat-pool environment and pool secrets to be configured. Also bumps the workflow tooling and regenerates all compiled lock files.

[rosebyte]

I'm not sure this is a good direction, as people shouldn't be sharing their PATs in a way that allows others to benefit from their tokens. I understand that it may seem like unnecessary fuss right now, but this free token grace period could end very abruptly. Moreover, it should be transparent who is using the tokens. If it's a GitHub agent, that should be visible. If it's a person, that should be visible too.

Could we instead consider a model where the pipeline runs under a GitHub agent by default and, when it gets throttled, there is an option to rerun it using a personal identity? Alternatively, we could simply start the pipeline under a personal identity from the outset, since that makes it clear who initiated the process.

Besides, wouldn't allowing others to use your PAT to acquire tokens be against the terms of service?

[rosebyte]

This might be necessary for huge mono-repos like dotnet/runtime, however, do we really need it for this repository with hardly any traffic (compared to the former one)?

[rosebyte]

I'm not sure this is a good direction, as people shouldn't be sharing their PATs in a way that allows others to benefit from their tokens. I understand that it may seem like unnecessary fuss right now, but this free token grace period could end very abruptly. Moreover, it should be transparent who is using the tokens. If it's a GitHub agent, that should be visible. If it's a person, that should be visible too.

Could we instead consider a model where the pipeline runs under a GitHub agent by default and, when it gets throttled, there is an option to rerun it using a personal identity? Alternatively, we could simply start the pipeline under a personal identity from the outset, since that makes it clear who initiated the process.

Besides, wouldn't allowing others to use your PAT to acquire tokens be against the terms of service?

[kotlarmilos]

I'm not sure this is a good direction, as people shouldn't be sharing their PATs in a way that allows others to benefit from their tokens. I understand that it may seem like unnecessary fuss right now, but this free token grace period could end very abruptly. Moreover, it should be transparent who is using the tokens. If it's a GitHub agent, that should be visible. If it's a person, that should be visible too.

Could we instead consider a model where the pipeline runs under a GitHub agent by default and, when it gets throttled, there is an option to rerun it using a personal identity? Alternatively, we could simply start the pipeline under a personal identity from the outset, since that makes it clear who initiated the process.

Besides, wouldn't allowing others to use your PAT to acquire tokens be against the terms of service?

This is a valid concern. The issue right now is that this repository does not have org-level billing, so the only way to run the workflows is with PATs. The main goal of this PR is to create the PATs in an environment that is restricted to protected branches, so their exposure on non-protected branches is limited.

On billing, the model you describe is the ideal one. Since we do not have org-level billing yet, I like you idea of using a PAT from single user since it is unlikely to hit the limits soon.