Install project in Dockerfile so the access CLI is on PATH

[somethingnew2-0]

Summary

After the FastAPI migration in #425 the click-based CLI is declared in setup.py via:

entry_points={
    "console_scripts": ["access = api.manage:cli"],
}

but the production Dockerfile only runs pip install -r ./api/requirements.txt and never installs the project itself, so the access console script is never created at /usr/local/bin/access. As a result, the CronJob examples in examples/kubernetes/cron-job-*.yaml (which use command: ["access", "sync"] / ["access", "notify", ...]) fail at startup with StartError exit code 128 — the OCI runtime can't exec a binary that isn't on PATH.

This PR copies setup.py into the build context and runs pip install --no-deps . after the requirements install. --no-deps preserves the pinned versions in requirements.txt as the source of truth for runtime deps (the install_requires in setup.py uses looser constraints).

Test plan

• docker build --target false -t access-test:local . succeeds locally; pip builds access-2.0-py3-none-any.whl from the in-tree setup.py and installs it cleanly with --no-deps.
• In the resulting image, which access returns /usr/local/bin/access and access --help lists the full click command tree (fix-role-memberships, fix-unmanaged-groups, import-from-okta, init, init-builtin-apps, notify, sync, sync-app-group-memberships). Subcommand help (access sync --help, access notify --help) shows the expected flags including --sync-group-memberships-authoritatively, --owner, and --role-owner.
• CMD is unchanged, so gunicorn ... api.asgi:app continues to launch the web app exactly as before.
• One of the examples/kubernetes/cron-job-*.yaml CronJobs runs to completion against the rebuilt image (consumer-side verification; not exercised here).