Incomplete naming schema and API usage patterns in py/insecure-cookie

1. The existing `cookie.isSensitive` predicate seems to miss common modern authentication token patterns. I have found some and listed them below.
2. The rule currently relies primarily on specific framework methods (e.g., set_cookie). It ignores direct HTTP manipulation, which is also very common.

code example:
```python
from flask import Flask, Response, make_response

app = Flask(__name__)

@app.route("/login")
def login():
resp = make_response("Logged in")
resp.set_cookie("authKey", "secret123") # $ Alert[py/insecure-cookie]
resp.set_cookie("accessToken", "secret123") # $ missing
resp.set_cookie("access_token", "secret123") # missing
resp.set_cookie("auth_token", "secret123") # missing
resp.set_cookie("jwt", "secret123") # $ missing
resp.set_cookie("oauth_token", "secret123") # $ missing

# cannot support this
resp.headers.add("Set-Cookie", "authKey=secret123") # missing

# This is also common, but it seems more difficult to support this.
from http.cookies import SimpleCookie
resp = make_response("Logged in")
cookie = SimpleCookie()
cookie["session"]['authKey'] = "secret123" # missing
# cookie["session"]["httponly"] = True
# cookie["session"]["secure"] = True
for key, morsel in cookie.items():
resp.headers.add('Set-Cookie', morsel.OutputString())
return resp
```

Start at the py/insecure-cookie rule and inspect the cookie.isSensitive predicate and the set_cookie handling described in the issue. Compare the listed token names and direct Set-Cookie examples against current behavior; done means the supported authentication-cookie patterns are detected without relying only on framework methods.

索引モデルが issue の本文から書いたものです。